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THE  GENERALIZED  RAILROAD  CROSSING:  A  CASE  STUDY  IN  FORMAL 
VERIFICATION  OF  REAL-TIME  SYSTEMS 


1  Introduction 

During  the  last  decade,  a  large  collection  of  formal  methods  have  been  invented  for  specifying, 
designing,  and  analyzing  real-time  systems.  To  compare  these  methods  and  to  better  understand 
their  use  in  developing  practical  real-time  systems,  one  of  us  (Heitmeyer)  has  defined  a  benchmark 
problem,  called  the  Generalized  Railroad  (GRC)  Crossing  [7].  The  problem  is  as  follows. 

The  system  to  be  developed  operates  a  gate  at  a  railroad  crossing.  The  railroad  crossing  I  lies 
in  a  region  of  interest  R,  i.e.,  ICR.  A  set  of  trains  travel  through  R  on  multiple  tracks  in 
both  directions.  A  sensor  system  determines  when  each  train  enters  and  exits  region  R.  To 
describe  the  system  formally,  we  define  a  gate  function  g{t)  €  [0,90],  where  g(i)  =  0  means 
the  gate  is  down  and  g{t)  =  90  means  the  gate  is  up.  We  also  define  a  set  {A,}  of  occupancy 
intervals,  where  each  occupancy  interval  is  a  time  interval  during  which  one  or  more  trains 
are  in  I.  The  ith  occupancy  interval  is  represented  as  A<  =  [r,-,i/,],  where  r.-  is  the  time  of  the 
tth  entry  of  a  train  into  the  crossing  when  no  other  train  is  in  the  crossing  and  j/,-  is  the  first 
time  since  r,'  that  no  train  is  in  the  crossing  (i.e.,  the  train  that  entered  at  r,-  has  exited  as 
have  any  trains  that  entered  the  crossing  after  Tj). 

Given  two  constants  and  ^2,  ^i  >  0,  ^2  >  0,  the  problem  is  to  develop  a  system  to  operate 
the  crossing  gate  that  satisfies  the  following  two  properties: 

Safety  Property:  t  G  U,  A,  =>  g{t)  =  0  (The  gate  is  down  during  all  occupancy  intervals.) 

Utility  Property:  t  ^  U,[r,  —  ^1,1/,  -f  ^2]  ^  g{t)  =  90  (The  gate  is  up  when  no  train  is  in 
the  crossing.) 

To  solve  the  GRC  problem,  real-time  researchers  have  applied  a  variety  of  formal  methods, 
including  process  algebraic  [9,  3,  1],  event-based  [10],  and  logic-based  approaches  [19,  11].  They 
have  also  used  various  mechanical  proof  systems,  including  PVS  [18],  EVES  [11],  and  FDR  [2],  to 
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formally  analyze  and  verify  their  solutions.  Reference  [5]  describes  three  early  efforts  to  solve  the 
GRC  problem. 

This  paper  describes  a  new  solution  of  the  GRC  based  on  the  Lynch- Vaandrager  timed  automaton 
model  [16,  15],  using  invariant  and  simulation  mapping  techniques  [12,  15,  14].  To  develop  the 
solution,  a  “formal  methods  expert”  (Lynch)  and  an  “applications  expert”  (Heitmeyer)  worked  closely 
together  to  refine  the  GRC  problem  statement  and  to  design  and  verify  an  implementation. 

Our  close  collaboration  was  in  sharp  contrast  to  the  limited  interaction  between  the  Naval  Re¬ 
search  Laboratory  (NRL)  group  that  originated  the  GRC  problem  and  the  formal  methods  groups 
that  developed  earlier  solutions.  In  the  earlier  work,  the  NRL  group  hmited  interaction  both  to  en¬ 
courage  original  solutions  and  to  prevent  some  groups  from  having  more  information  and  thus  unfair 
advantage  over  other  groups.  While  these  early  efforts  produced  a  variety  of  solutions  and  many 
insights  into  the  relative  strengths  and  weaknesses  of  the  different  formalisms,  they  suffered  from 
two  limitations.  First,  because  the  original  problem  statement  was  somewhat  ambiguous,  each  group 
solved  a  slightly  different  problem,  which  caused  difficulties  in  comparing  the  solutions.  Second,  the 
limited  interaction  meant  that  deficiencies  in  the  GRC  problem  statement  went  uncorrected.  Our 
collaboration  allowed  us  quickly  to  identify  and  correct  these  deficiencies.  It  also  led  us  to  represent 
the  problem  and  its  solution  in  a  form  that  is  both  understandable  to  applications  experts  and  usable 
by  formal  methods  experts  for  verification. 

The  rest  of  the  paper  is  organized  as  follows.  Section  2  describes  our  approach:  general  principles 
for  applying  formal  methods  to  specify  and  verify  real-time  systems,  our  formal  model  and  proof 
techniques,  and  an  outline  of  how  we  applied  the  formal  methods  to  the  GRC  problem.  Section  3 
presents  our  highest-level  problem  specification,  intended  to  be  understood  by  applications  experts; 
it  improves  over  the  original  problem  statement  given  above  by  resolving  some  ambiguities.  Section  4 
contains  a  secondary  operational  specification,  intended  to  be  useful  in  formal  verification.  Section  5 
contains  our  system  implementation.  Section  6  contains  the  main  correctness  proof.  Section  7 
describes  extensions  to  more  realistic,  continuous  models  of  the  real  world  components.  Section  8 
evaluates  our  solution  and  method.  Several  appendices  provide  background  on  the  formal  methods 
we  use,  plus  two  proofs  about  the  high-level  specification.  A  concise  version  of  this  report,  which 
omits  the  details  of  the  proofs,  appears  in  [8]. 

2  Our  Approach 

In  this  section,  we  describe  our  approach  to  solving  the  GRC  problem.  Section  2.1  contains  some 
general  principles  for  applying  formal  methods  to  real-time  systems.  Section  2.2  contains  a  descrip¬ 
tion  of  the  timed  automaton  model  and  of  invariant  and  simulation  mapping  proof  methods.  Section 
2.3  contains  an  overview  of  how  we  apply  these  formal  methods  to  the  GRC  problem. 

2.1  Formal  Methods  for  Real-Time  Systems 

Applying  formal  methods  to  real-time  systems  involves  three  steps:  system  requirements  specifica¬ 
tion,  design  of  an  implementation,  and  verification  that  the  implementation  satisfies  the  specification. 
This  process  has  feedback  loops.  Once  specified,  the  requirements  must  be  revised  when  later  steps 
expose  omissions  and  errors.  The  same  is  true  of  the  designed  implementation. 
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All  three  steps  require  close  collaboration  between  the  formal  methods  expert  and  the  applications 
expert.  The  role  of  the  formal  methods  expert  is  to  produce  formal  descriptions  of  both  the  system 
requirements  and  the  selected  implementation  and  to  prove  formally  that  the  latter  satisfies  the 
former.  The  role  of  the  applications  expert  is  to  work  closely  with  the  formal  methods  expert  to 
identify  the  “real”  requirements  and  to  ensure  that  the  specified  implementation  is  acceptable.  In 
our  collaboration,  much  of  the  dialogue  focused  on  the  system  requirements.  Once  the  requirements 
specification  wjis  acceptable,  defining  and  verifying  an  implementation,  while  labor-intensive  and 
time-consuming,  was  relatively  straightforward. 

A  system  requirements  specification  describes  all  acceptable  system  implementations  [6].  It  has 
two  parts:  (1)  A  set  of  formal  models  describing  the  computer  system  at  an  abstract  level,  the 
environment  (here,  the  trains  and  the  gate),  and  the  interface  between  them.  (2)  Formal  statements 
of  the  properties  that  the  system  must  satisfy. 

In  developing  the  GRC  solution,  we  applied  the  following  seven  software  engineering  principles. 
The  first  five  concern  the  requirements  specification.  The  sixth  concerns  the  implementation  and  its 
verification,  and  the  seventh  is  applicable  to  all  three  steps. 

1.  Avoid  underspecifying  system  requirements.  The  original  problem  statement  lacked  necessary 

information  about  the  various  constants.  For  example,  the  statement  did  not  constrain  the 
constant  ^i.  A  simple  analysis  shows  that  we  should  assume  that  +  (2-^1,  where 

€2  is  the  maximum  time  and  ci  the  minimum  time  that  a  train  requires  to  travel  from  entry 
into  R  to  the  crossing  and  is  the  maximum  time  needed  to  lower  the  gate. 

2.  Avoid  overspecifying  system  requirements.  For  example,  while  the  function  g  is  an  acceptable 
gate  model,  the  GRC  problem  can  be  solved  using  a  simpler,  discrete  model  -  one  that  repre¬ 
sents  the  gate  as  being  in  one  of  four  states  -  up,  going-down,  down,  and  going-up.  Our  solution 
uses  the  simpler  model,  but  we  show  in  Section  7  how  to  extend  our  results  to  the  original  gate 
model. 

For  another  example,  the  Utility  Property  stated  above  does  not  rule  out  solutions  in  which 
the  last  train  leaves  the  crossing  at  time  t  but  within  the  interval  [t,  f-|-^2]  the  gate  goes  first  up 
and  then  down  rapidly  before  the  gate  is  raised  for  the  second  (and  final)  time.  Such  solutions, 
though  not  to  be  encouraged,  should  not  be  excluded.  The  essential  system  properties  are  that 
the  gate  must  be  down  when  a  train  is  in  the  crossing  and  that  the  gate  must  be  up  during  the 
specified  intervals  when  no  train  is  in  the  vicinity.  During  other  times,  we  do  not  care  what 
the  gate  does. 

3.  Make  sure  the  specified  system  behavior  is  reasonable.  For  example,  suppose  a  train  exits  the 
crossing  at  time  t  and  another  train  is  scheduled  to  enter  the  crossing  by  time  t  +  lup  +  ldown' 
Then  there  is  insufficient  time  for  even  one  car  to  travel  through  the  crossing,  and  thus  the 
Utility  Property  fails  to  achieve  its  practical  purpose.  To  rule  out  such  useless  activity,  we 
modify  the  original  problem  statement  to  only  require  the  gate  to  be  raised  if  sufficient  time,  6, 
exists  for  at  least  one  car  to  travel  through  the  crossing.  A  trivial  modification  of  the  original 
problem  statement  to  include  6  appears  in  Appendix  D. 

4.  Specify  the  system  requirements  axiomatically  rather  than  operationally.  In  the  original  problem 
statement,  both  the  Safety  Property  and  the  Utility  Property  are  expressed  as  axioms.  Each 
axiom  describes  a  relationship  that  is  supposed  to  hold  between  the  two  components  of  the 
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system  environment,  namely,  the  trains  and  the  crossing  gate.  Thus  the  required  system  prop¬ 
erties  are  properties  of  the  environment.  Neither  axiom  mentions  the  computer  system.  Also 
the  two  axioms  are  stated  independently,  making  it  easy  to  modify  the  individual  properties.  ’ 

In  the  present  study,  we  initiaUy  reformulated  the  requirements  specification  operationaUy,  as 
a  timed  automaton.  This  reformulation  incorporated  both  the  Safety  and  Utility  Properties 
into  a  single  automaton  description,  thus  losing  the  advantage  of  independence.  Also,  our 
reformulation  was  stronger  than  the  original,  specifying  some  aspects  of  what  the  computer 
system  should  do  rather  than  just  describing  properties  that  the  system  needed  to  guarantee  in 
the  environment.  Finally,  the  operational  style  of  the  reformulation  was  harder  for  applications 
experts  to  understand.  Our  final  version  of  the  specification,  which  appears  in  Section  3  is 

^omatic.  Like  the  original  formulation,  it  describes  the  two  properties  as  independent  axioms 
about  the  environment. 

5.  Provide  an  operational  secondary  specification  plus  a  formal  proof  that  the  operational  specifica¬ 
tion  implements  the  axiomatic  specification.  Although  it  is  desirable  to  start  with  an  axiomatic 
specification,  the  types  of  proofs  we  do  rest  on  operational,  automaton  versions  of  the  speci¬ 
fication  and  implementation.  Therefore,  we  present  a  secondary  requirements  specification  in 
erms  of  timed  automata  and  prove  that  the  operational  requirements  specification  implements 
ttie  original  axiomatic  specification. 

As  in  many  applications  of  formal  methods,  we  initially  neglected  to  provide  a  formal  proof  of 
the  correspondence  between  the  original  specification  and  the  reformulation  within  our  frame¬ 
work.  Without  such  a  proof,  there  is  no  assurance  that  the  properties  satisfied  by  the  system 
implementation  are  the  ones  that  are  really  required.  In  our  case,  while  it  was  immediately  ob¬ 
vious  that  the  statement  of  the  Safety  Property  in  our  operational  specification  was  equivalent 

o"ginal  statement  of  the  Safety  Property,  the  correspondence  between  the  two  versions 
of  the  Utihty  Property  was  not  so  clear. 

6.  Provide  a  formal  model  for  the  implementation  and  a  proof  that  it  implements  the  operational 

specification.  The  implementation  should  be  described  using  the  same  model  that  is  used  for  the 
operational  specification,  or  at  least  one  that  is  compatible.  The  proof  that  the  implementation 
meets  the  specification  can  be  done  using  a  variety  of  methods.  It  might  be  done  by  hand  as 
in  this  paper,  or  with  computer  assistance.  ' 

7.  Exp^ss  the  system  requirements  specification,  the  implementation,  and  the  formal  proofs  so 

a  they  are  understandable  to  applications  experts.  If  the  requirements  specification  and  the 
specification  of  the  implementation  are  difficult  to  understand,  the  applications  expert  cannot 
be  confident  that  the  right  requirements  have  been  specified  and  that  the  implementation 
IS  acceptable  The  same  holds  for  the  formal  proofs:  the  applications  expert  must  be  able 
to  understand  the  proofs.  This  gives  him/her  a  deep  understanding  of  how  and  why  the 
system  works  and  how  future  changes  are  likely  to  affect  system  behavior.  To  increase  their 
understandabihty,  both  the  formal  specifications  and  the  proofs  should  be  based  on  standard 
models  such  as  automaton  models,  standard  notations,  and  standard  proof  techniques  such  as 
invanants  and  simulation  mappings.  To  the  extent  feasible,  applications  experts  should  not  be 
required  to  learn  new  notations  or  proof  techniques. 
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2.2  The  Formal  Framework 


The  formal  method  we  used  to  specify  the  GRC  problem  and  to  develop  and  verify  a  solution 
represents  both  the  computer  system  and  the  system  environment  as  timed  automata,  according  to 
the  definitions  of  Lynch  and  Vaandrager  [16,  15].  A  timed  automaton  is  a  very  general  automaton, 
i.e.,  a  labeled  transition  system.  It  is  not  finite-state:  for  example,  the  state  can  contain  real¬ 
valued  information,  such  as  the  current  time  or  the  position  of  a  train  or  crossing  gate.  This  makes 
timed  automata  suitable  for  modeling  not  only  computer  systems  but  also  real-world  entities  such  as 
trains  and  gates.  We  base  our  work  directly  on  an  automaton  model  rather  than  on  any  particular 
specification  language,  programming  language,  or  proof  system,  so  that  we  may  obtain  the  greatest 
flexibility  in  selecting  specification  and  proof  methods.  The  formal  definition  of  a  timed  automaton 
appears  in  Appendix  A. 

The  timed  automaton  model  supports  description  of  systems  as  collections  of  timed  automata, 
interacting  by  means  of  common  actions.  In  our  example,  we  define  separate  timed  automata  for  the 
trains,  the  gate,  and  the  computer  system;  the  common  actions  are  sensors  reporting  the  arrival  of 
trains  and  actuators  controlling  the  raising  and  lowering  of  the  gate. 

An  important  special  case  of  the  model,  describable  in  a  particularly  simple  way,  is  the  MMT 
automaton  model  [17],  developed  by  Merritt,  Modugno  and  Tuttle.  An  MMT  automaton  consists  of 
a  collection  of  “tasks”  (i.e.,  “processes”)  sharing  common  data,  where  each  task  has  an  upper  bound 
and  a  lower  bound  on  the  time  between  its  events.  This  special  case  is  sufficient  for  describing  several 
of  our  components;  in  particular,  the  trains  and  the  discrete  version  of  the  gate.  Formal  definitions 
of  the  MMT  model  are  given  in  Appendix  B.  Our  other  components,  e.g.,  the  computer  system, 
cannot  be  expressed  in  the  MMT  style,  so  we  describe  them  directly  in  terms  of  the  general  model. 
Instead  of  thinking  of  the  MMT  model  as  a  different  model,  we  often  find  it  useful  to  regard  it  as 
simply  a  way  of  describing  a  large  subclass  of  timed  automata. 

2.3  Applying  Formal  Methods  to  GRC 

Our  solution  contains  four  system  descriptions:  AxSpec,  the  axiomatic  requirements  specification; 
OpSpec,  the  operational  requirements  specification;  Systlmpl,  the  discrete  system  implementation; 
and  Systlmpl',  a  system  implementation  with  a  continuous  gate  model.  Figure  1  illustrates  the  four 
specifications  and  how  they  are  related. 

The  top-level  requirements  specification,  AxSpec,  contains  timed  automata  describing  the  com¬ 
puter  system  and  its  environment  (the  trains  and  gate),  and  axioms  expressing  the  Safety  and  Utility 


AxSpec 


Trains 


1  jr 
rrTi 


Gate 


OpSpec 


Trains 


Gate 


\Safety\\ Utmt)\  -#  -^OpProps^  ■J^  OpProps 


}-l 


CompSpec  ]■  -j  CompSpec  1  j  Complmpl  \ 


Systlmpl 


Trains 


Gate 


Systlmpl' 


Trains 


OpProps 


Figure  1:  The  four  system  descriptions  and  how  they  are  related.  In  OpSpec,  OpProps  incorporates 
the  Safety  and  Utility  properties  into  the  automaton  that  results  from  composing  Trains,  Gate,  and 
CompSpec. 
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Properties.  The  Safety  Property  states  that  any  time  there  is  a  train  in  the  crossing,  the  gate  must 
be  down.  The  Utility  Property  states  that  the  gate  is  up  unless  there  is  a  train  in  the  vicinity. 
Formally,  these  axioms  are  properties  added  to  the  composition  of  three  timed  automata:  Trains, 

Gate,  and  CompSpec,  a  trivial  specification  of  the  computer  system  interface.  Figure  2  illustrates 
AxSpec. 

Next,  because  it  is  easier  to  use  in  proving  correctness,  we  produce  a  secondary,  more  opera¬ 
tional  requirements  specification  in  the  form  of  a  timed  automaton  OpSpec.  We  show  that  OpSpec 
implements  AxSpec. 

Next,  we  describe  our  computer  system  implementation  as  a  timed  automaton,  Compimpl.  Cor¬ 
rectness  means  that  Compimpl,  when  it  interacts  with  Trains  and  Gate,  guarantees  the  Safety  and 
Utihty  Properties.  To  show  this,  we  prove  that  Systlmpl,  the  composition  of  Compimpl,  Trains  and 
Gate  provides  the  same  view  to  the  environment  components.  Trains  and  Gates,  as  the  operational 
specification  OpSpec.  This  part  of  the  proof  follows  well-established,  stylized  invariant  and  simu¬ 
lation  mapping  methods,  which  is  why  we  moved  from  the  axiomatic  style  of  specification  to  the 
operational  style.  All  of  these  proofs  can  be  verified  using  current  mechanical  proof  technology. 

In  both  specification  automata,  AxSpec  and  OpSpec,  and  also  in  the  implementation  automaton 
bystlmpl,  time  information  is  built  into  the  state.  Timing  information  consists  of  the  current  time 
plus  some  deadline  information,  such  as  the  earliest  and  latest  times  that  a  train  that  has  entered  R 
wiU  actually  enter  the  crossing.  The  correctness  proof  proceeds  by  first  proving  by  induction  some 
invariants  about  the  reachable  states  of  Systlmpl.  The  main  work  in  the  proof  of  the  Safety  Property 

IS  done  by  means  of  these  invariants.  An  interesting  feature  of  the  proofs  is  that  the  invariants 
involve  time  deadline  information. 

Next,  we  show  a  “simulation  mapping”  between  the  states  of  Systlmpl  and  OpSpec,  again  by 
mduction;  this  is  enough  to  prove  the  Utility  Property.  Appendix  C  contains  formal  definitions 
for  simulation  mappings  and  the  correctness  properties  they  guarantee.  Like  the  invariants,  the 

simu  ations  involve  time  deadUne  information,  in  particular,  they  include  inequalities  between  time 
deadhnes. 

FinaUy,  we  observe  that  our  main  proofs  yield  a  weaker  result  that  what  we  really  want.  Namely 
we  have  worked  with  an  abstract,  discrete  model  of  the  trains  and  gate  rather  than  with  a  realistic 
model  that  allows  continuous  behavior.  And  we  have  only  shown  that  the  “admissible  timed  traces” 
i.e.  the  sequences  of  externally  visible  actions,  together  with  their  times  of  occurrence,  are  preserved,’ 
rather  than  all  aspects  of  the  environment’s  behavior.  We  conclude  by  showing  that  we  have  not  lost 
any  generality  by  proving  the  weaker  results.  In  particular,  preservation  of  admissible  timed  traces 


Figure  2:  AxSpec  is  the  composition  of  Trains,  Gate,  and  CompSpec,  constrained  by  the  Safety  and 
Utility  properties. 
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actually  implies  preservation  of  all  aspects  of  the  environment’s  behavior.  Further,  the  results  extend 
to  Systlmpl',  a  system  implementation  with  a  more  realistic  environment  model.  Both  extensions  are 
obtained  as  corollaries  of  the  results  for  admissible  timed  traces  of  the  discrete  model,  using  general 
results  about  composition  of  timed  automata. 

3  Axiomatic  Specification 

We  begin  with  a  high  level  axiomatic  specification,  AxSpec,  describing  the  problem  in  terms  most 
easily  understood  by  application  experts.  We  express  the  axioms  solely  in  terms  of  the  environment. 

We  first  define  two  timed  automata,  Trains  and  Gate,  which  are  abstract  representations  of  the 
trains  and  gate,  respectively.  These  two  components  do  not  interact  directly.  We  then  define  a 
trivial  automaton  CompSpec,  which  interacts  with  both  Trains  and  Gate  via  actions  representing 
sensors  and  actuators.  CompSpec  describes  nothing  more  than  the  interface  that  the  computer 
system  must  have  with  the  environment.  AxSpec  is  obtained  by  composing  these  three  automata 
and  then  imposing  the  Safety  and  Utility  Properties  on  the  composition;  see  Figure  2.  Formally,  the 
two  properties  are  restrictions  on  the  executions  of  the  composition.  The  Safety  Property  is  just  a 
restriction  on  the  states  that  occur  in  the  execution,  while  the  Utility  Property  is  a  more  complex 
temporal  condition. 

3,1  Parameters  and  Other  Notation 

We  use  the  notation  r ,  r' ,  etc.  to  denote  (railroad)  trains.  We  use  I  to  denote  the  railroad  crossing, 
R  to  denote  the  region  from  where  a  train  passes  a  sensor  until  it  exits  the  crossing,  and  P  to  denote 
the  portion  of  R  prior  to  the  crossing.  We  define  some  positive  real-valued  constants: 

•  ei,  a  lower  bound  on  the  time  from  when  a  train  enters  R  until  it  reaches  I. 

•  f2,  an  upper  bound  on  the  time  from  when  a  train  enters  R  until  it  re2u;hes  7. 

•  6,  the  minimum  useful  time  for  the  gate  to  be  up.  (For  example,  this  might  represent  the  minimum  time  for  a 

Ccir  to  pass  through  the  crossing  safely.) 

•  Ifdown’  upper  bound  on  the  time  to  lower  the  gate  completely. 

•  7ijp,  ein  upper  bound  on  the  time  to  raise  the  gate  completely. 

•  upper  bound  on  the  time  from  the  start  of  lowering  the  gate  until  some  train  is  in  /. 

•  $2,  an  upper  bound  on  the  time  from  when  the  last  train  leaves  I  until  the  gate  is  up  (unless  the  raising  is 

interrupted  by  another  train  getting  “close”  to  I). 

•  R,  a.n  arbitrarily  small  constant  used  to  take  care  of  some  technical  race  conditions.* 

We  need  some  restrictions  on  the  values  of  the  various  constants: 

1-  Cl  <  £2. 

2-  >  Ifdown-  bom  when  a  train  arrives  until  it  reaches  the  crossing  is  sufficiently  large  to  allow  the 

gate  to  be  lowered.) 

3-  6  >  Idown  +  -  Cl .  (The  time  allowed  between  the  start  of  lowering  the  gate  and  some  train  reaching  I 

is  sufficient  to  allow  the  gate  to  be  lowered  in  time  for  the  fastest  train,  and  then  to  accommodate  the  slowest 
train.  The  time  idown  ^  “®®ded  to  lower  the  gate  in  time  for  the  fastest  train,  but  the  slowest  train  could  take 
an  additional  time  e2  —  fi-  The  is  a  technicality.) 

4.  ^2  >  7up.  (The  time  allowed  for  raising  the  gate  is  sufficient.) 

*  These  arise  because  the  model  allows  more  than  one  event  to  happen  at  the  same  real  time. 
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3.2  T'rains 


We  model  the  Trains  component  as  an  MMT  automaton  with  no  input  or  internal  actions,  and  three 
types  of  outputs,  enterR(^r),  €nterl(^r'),  and  ca:it(r),  for  each  train  r. 

Actions: 

Input: 

none 

Output: 

enterR{r),  r  a  train 
enterj[r),  r  a  train 
exit(r),  r  a  train 


The  state  consists  of  a  status  component  for  each  train,  just  saying  where  it  is. 
State: 


for  each  train  r: 

r. status^  {not-here,  P,I},  initially  not-here 


The  State  transitions  are  described  by  specifying  the  “preconditions”  under  which  each  action 
can  occur  and  the  “effect”  of  each  action.  We  use  5  to  denote  the  state  before  the  event  occurs 
and  s  the  state  afterwards.  We  use  the  convention  that  if  a  state  component  is  not  mentioned,  it 
IS  unchanged  (although  sometimes,  to  resolve  ambiguities  or  for  emphasis,  we  say  explicitly  that  a 
component  is  unchanged). 

Transitions: 


enterKj) 

Precondition: 

s.r. status  =  not-here 
Effect: 

s'. r. status  =  P 


exiffr) 

Precondition: 

s.r. status  =  I 
Effect: 

s'. r. status  =  not-here 


enterl{r) 

Precondition: 

s.r. status  =  P 
Effect: 

s'. r. status  =  1 


In  this  automaton  (and  for  all  the  other  MMT  automata  in  this  paper),  we  make  each  non-input 
actmn  a  task  by  itself.  We  only  specify  trivial  bounds  (that  is,  [0,oo])  for  the  €nterR{r)  and  exit{r) 
actions.  For  each  enterl{r)  action,  we  use  bounds  [ci,C2].  This  means  that  from  the  time  when  any 
tram  r  has  reached  R,  it  is  at  least  time  d  and  at  most  time  cj  until  the  train  reaches  I. 

We  use  the  pneraJ  construction  described  in  Appendix  B  to  convert  this  automaton  to  a  timed 
automaton.  This  construction  involves  adding  some  components  to  the  state  -  a  current  time  com¬ 
ponent  now,  and  first  and  last  components  for  each  task,  giving  the  earliest  and  latest  times  at  which 
an  action  of  each  task  can  occur,  once  the  task  is  enabled.  The  transition  relation  is  augmented  with 
conditions  to  enforce  the  bound  assumptions,  that  is,  that  an  event  cannot  happen  before  its  first 
time,  and  that  time  cannot  pass  beyond  any  last  time.  In  this  case,  only  the  state  components  now, 
and  firs1{enterI{T))  and  last{enterl{r))  for  each  r  contain  nontrivial  information,  so  we  ignore  the 
other  cases.  Applying  this  construction  yields  the  timed  automaton  with  the  same  actions  and  the 
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following  states  and  transitions.  (In  this  automaton  description,  as  weU  as  elsewhere  in  the  paper, 
we  sometimes  omit  mention  of  the  state  where  there  is  no  ambiguity.) 

State: 

now,  a  nonnegative  real,  initially  0 
for  each  train  r: 

r. status  E  {not-here,P,I},  initially  not-here 
first{enterl{r)),  a  nonnegative  real,  initially  0 
last{enter^r)),  a  nonnegative  real  or  oo,  initially  oo. 

Transitions: 
enterR{r) 

Precondition: 

s.r. status  =  not-here 
Effect: 

s'. T. status  =  P 
s' .first{enter^r))  =  no«/+ei 
s' .last(_enterl{r))  =  now-^-  cq 

enter^r) 

Precondition: 
s.r. status  =  P 
now>  s.first(enterl(r)) 

Effect: 

s'. T. status  =  I 
s'  .firsi^enterSj))  =  0 
s' .last(enterl{r))  =  oo 

Lemma  3.1  In  any  reachable  state  of  Trains: 

For  any  r  such  that  r.status  =  P,  first{enterl{r))  +  62  -  ei  =  last{enterl{r)). 

Proof:  By  induction  on  the  length,  i.e.,  the  total  number  of  non-time-passage  and  time-passage 
steps,  of  an  execution.  Because  €2  —  Ci  is  a  constant,  we  need  only  consider  actions  that  change 
first(enter]f^r)),  last{enterl(r))  or  make  r.status  =  P,  namely,  enterR{r)  and  enterl{r).  The  actions 
exit{r)  and  i/{At)  do  not  affect  the  statement. 

After  0  steps,  the  claim  is  vacuously  satisfied.  Assume  the  claim  is  true  after  m  steps.  We  must 
prove  it  is  true  after  m  -f-  1  steps.  For  enterl{r),  the  claim  is  vacuously  satisfied.  For  enterR{r),  the 
effect  is  s'. r.status  =  P.  Then,  s' .first(enterl(r))  =  noir-l-Ci  and  s' .last{enterl{r))  =  now-\-e2,  which 
implies  that  s' .firslfenterl{r))  -f  €2  ~  Ci  =  s' .lastfenterFj))  as  required.  ■ 

3.3  Gate 

We  model  the  gate  as  another  MMT  automaton,  this  one  with  inputs  lower  and  raise  and  outputs 
down  and  up. 

Actions: 

Input: 

lower 

raise 

Output: 

down 

up 


exit(r) 

Precondition: 

s.r.  status  =  I 
Effect: 

s'  .r.status  =  not-here 

./(At) 

Precondition: 

for  all  r,  s.rjot«-|-  At  <  s.last(^enterl[r)) 
Effect: 

s'.now=i  s.now-i-  At 
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The  state  consists  of  a  single  status  component: 


State; 

status  e  {up,  down,  going-up,  going-down],  initially  up 


Transitions: 

lower 

Effect: 

if  s. status  £  {up,  going-up]  then 
s'. status  =  going-down 
else  unchanged  status 


down 

Precondition: 

s. status  =  going-down 
Effect: 

s'  .status  =  down 


up 

Precondition: 

s. status  =  going-up 
Effect: 

s'  .status =  up 

The  time  bounds  are  down.  [0,7^Qy,^,  and  up:  [0, 7up],  where  jup  and  'if(]Qrn„  are  upper  bounds 
on  the  time  required  for  the  gate  to  be  raised  and  lowered.  To  build  time  into  the  state,  the  state 
components  now,  last(up),  and  last[down)  are  added  to  produce  the  following  states  and  transitions. 

State: 

status  €  {op,  down,  going-up,  going-down] ,  initially  up 
now,  a  nonnegative  real,  initially  0 
last(down),  a  nonnegative  real  or  oo,  initially  oo 
last(up),  a  nonnegative  real  or  oo,  initially  oo 


raise 

Effect: 

if  s. status  £  {down,  going-down]  then 
s'  .status  =  going-up 
else  unchanged  status 


Transitions; 

lower 

Effect: 

it  s. status  £  {up,  going- up]  then 
a  .status  =  going-down 
s'.last{down)  =  nou)+  ijouin 
s  .last{up)  =  oo 

else  unchanged  status,  hst{down),  last{up) 


raise 

Effect: 

if  s. status  £  {down,  going-down]  then 
s'. status  =  going-up 
s'.last(up)  =  noted-  7op 
s'  .last[down)  =  oo 

else  unchanged  status,  last{down),  last(up) 


down 

Precondition: 

s. status  =  going-down 
Effect: 

s'  .status  =  down 
s'.lasl(down)  =  oo 


Precondition: 

s. status  =  going-up 
Effect: 

s'  .status  =  op 
3'.lait{up)  =  oo 


i/(At) 

Precondition: 

a. noted-  At  <  s.last(up) 
a. note -f  At  <  s.last^down) 
Effect: 

a'. note  =  a. noted- At 
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3.4  CompSpec 

We  model  the  computer  system  interface  as  a  trivial  MMT  automaton  CompSpec  with  inputs 
enterR{r)  and  exit{r)  for  each  train  r,  and  outputs  lower  and  raise. 

Actions: 

Input: 

enterRlr),  r  a  train 
exH(r),  r  a  train 
Output: 
lower 
raise 


CompSpec  receives  sensor  information  when  a  train  arrives  in  the  region  R  and  when  it  leaves 
the  crossing  J.  Note  that  CompSpec  does  not  have  an  input  action  enterl(ry,  this  expresses  the 
assumption  that  there  is  no  sensor  that  informs  the  system  when  a  train  actually  enters  the  crossing. 
CompSpec  has  just  a  single  state.  Inputs  and  outputs  are  always  enabled,  and  cause  no  state  change. 
There  are  no  timing  requirements. 

Transitions: 

enterR(r) 

Effect: 
none 

exit(r) 

Effect: 
none 


3.5  AxSpec 

To  get  the  full  specification,  we  compose  the  three  MMT  automata  given  above.  Trains,  Gate  and 
CompSpec,  yielding  a  new  MMT  automaton.  But  this  is  not  enough:  we  then  add  constraints  to 
express  the  correctness  properties  in  which  we  are  interested.  Formally,  these  constraints  are  axioms 
about  an  admissible  timed  execution  a  of  the  composition  automaton: 

1.  Safety  Property 

All  the  states  in  a  satisfy  the  following  condition: 

If  Trains.r. status  =  I  for  any  r,  then  Gate.status=  down. 

2.  Utility  Property 

If  s  is  a  state  in  a  with  s.  G ate. status  ^  up,  then  at  least  one  of  the  following  conditions  holds. 

(a)  There  exists  s'  preceding  (or  equal  to)  s  in  a  with  s'.  Trains.r. status  =  I  for  some  r  and  s'. now  >  s.now—^2. 

(b)  There  exists  s'  foUowing  (or  equ<il  to)  s  in  a  with  s'  .Trains.r. status  =  I  for  some  r  and  s'. now  <  s.now+^i. 

(c)  There  exist  two  states  s'  and  s"  in  a,  with  s'  preceding  or  equal  to  s,  s"  following  or  equal  to  s, 

s'  .Trains.r.  status  =  J  for  some  r,  s"  .Trains.r. status  =  I  for  some  r,  and  s".now—  s'. now  <  +$2  +  6. 


lower 

Precondition: 

true 

Effect: 

none 

raise 

Precondition: 

true 

Effect: 

none 
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The  Safety  and  Utibty  properties  are  stated  independently.  The  Safety  Property  is  an  assertion 
about  ^  the  states  reached  in  a,  saying  that  they  all  satisfy  the  critical  safety  property.  In  contrast, 

^  temporal  property  with  a  somewhat  more  complicated  structure,  which  says 

•  ^  ^  ^  preceding  state  or  an  imminent  foDowing  state 

m  which  a  train  is  in  I.  The  third  condition  takes  care  of  the  special  case  where  there  is  both  a 
recent  state  and  an  imminent  state  in  which  some  train  is  in  /;  although  these  states  are  not  quite 
as  recent  or  imminent  as  required  by  the  first  two  cases,  there  is  insufficient  time  for  a  car  to  pass 
rough  the  crossing.  In  Appendix  D,  we  show  that  the  above  statement  of  the  Safety  and  Utility 
Properties  is  equivalent  to  a  trivial  modification  of  the  original  problem  statement. 

We  define  the  admissible  timed  executions  of  AxSpec,  atexcesiAxSpec),  to  be  the  set  of  admissible 
tiined  executions  of  the  composition  automaton  that  satisfy  the  Safety  and  Utility  axioms.  Also  we 
define  the  admissible  timed  traces  of  AxSpec,  attraces{ AxSpec),  to  be  the  set  of  timed  traces  of  such 

executions  These  are  analogous  to  the  notions  of  admissible  timed  execution  and  admissible  timed 
traces  used  for  timed  automata. 

3.6  Implementation  Requirements 

An  implementaUon  of  AxSpec  uses  a  new  timed  automaton,  called  Complmpl,  with  the  same  interface 
as  CompSpec.  Complmpl  will  be  composed  with  the  same  Trains  and  Gate  automata  given  above 
yielffing  a  new  system  Systimpl.  The  system  5ysf/mp/ should  produce  executions  that,  when  projected 
on  the  environment  ( Trains  composed  with  Gate),  yields  behavior  that  is  also  produced  by  the  system 
specification  AxSpec.  More  precisely,  for  every  admissible  timed  execution  a  of  Systimpl,  there 
should  be  a  corresponding  admissible  timed  execution  a'  of  AxSpec  such  that  a'\Tmins  x  Gate  = 
a\ drains  X  Gate.  That  is,  the  two  executions  project  identically  on  the  Trams  and  Gate  automata. 

4  Operational  Spec 

of  a  timed  automaton  together  with  some  axioms  that  describe 
restrictions  on  the  automaton  s  executions,  the  secondary  operational  specification,  OpSpec,  is  simply 
a  timed  automaton  -  aU  required  properties  are  built  into  the  automaton  itself  as  restrictions  on  th^ 
tate  set  and  on  the  actions  that  are  permitted  to  occur.  As  a  result,  OpSpec  is  probably  harder  for 
an  apphcation  expert  to  understand  than  AxSpec.  But  it  is  easier  to  use  in  proofs  (at  least  for  the 
s  yle  of  verification  we  are  using).  Thus  we  regard  OpSpec  as  an  intermediate  specification  rather 
than  a  true  problem  specification;  we  only  require  that  OpSpec  implement  AxSpec,  not  necessarily 
vice  versa,  and  that  all  implementations  of  interest  satisfy  OpSpec. 

The  two  types  of  specifications  are  also  different  in  another  respect:  while  AxSpec  preserves  the 
independence  of  the  Safety  and  Utility  Properties,  OpSpec  does  not.  When  a  coUection  of  separate 
properties  are  specified  by  an  automaton,  the  properties  usuaUy  become  intertwined. 

4.1  The  Specification 

To  obtain  OpSpec,  we  first  compose  Trains,  Gate,  and  CompSpec,  and  then  incorporate  the  Safety 
and  Utihty  Properties  into  the  automaton  itself.  Formally,  the  modified  automaton  is  obtained 
from  the  composition  by  restricting  it  to  a  subset  of  the  state  set,  then  adding  some  additional 
s  a  e  components,  and  finally  modifying  the  definitions  of  the  steps  to  describe  their  dependence  on 
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and  their  effects  on  the  new  state  components.  Although  the  composition  of  the  three  component 
automata  is  an  MMT  automaton,  the  modified  version  is  not  -  it  is  a  timed  automaton. 

First,  to  express  the  Safety  Property,  we  restrict  the  states  to  be  those  states  of  the  composition 
that  satisfy  the  following  invariant:  “If  Trainss. status  =  I  for  any  r,  then  Gate.status  =  down.'" 

Second,  the  time-bound  restrictions  expressed  by  the  Utility  Property  are  encoded  as  restrictions 
on  the  steps.  The  strategy  is  similar  to  that  used  in  Appendix  B  to  encode  MMT  time  bound 
restrictions  into  the  steps  of  a  timed  automaton  -  it  involves  adding  explicit  deadline  components. 
We  describe  the  modifications  in  two  pieces: 

1.  The  time  from  when  the  gate  starts  going  down  until  some  train  enters  I  is  bounded  by  ^i.  To 
express  this  restriction  formally,  we  add  to  the  state  of  the  composed  system  a  new  deadline 
lasti ,  representing  the  latest  time  in  the  future  that  a  train  is  guaranteed  to  enter  I.  Initially, 
this  is  set  to  oo,  meaning  that  there  is  no  such  scheduled  requirement.  To  add  this  new 
component  to  OpSpec,  we  include  the  following  new  effects  in  two  of  the  actions: 

Transitions: 

lower  enterI{T) 

Effect:  Effect; 

if  s. Gate. status  £  {up,  going-up}  s'. lasti  =  oo 

a.nd  s.lasti  =  oo  then 
s'. lasti  =  now-t-  (i 
else  unchanged  lasti 


There  is  also  a  new  precondition  added:  the  time-passage  action  cannot  cause  time  to  pass 
beyond  lasti.  This  means  that  whenever  the  gate  starts  moving  down,  some  train  must  enter 
I  within  time  .  The  new  effect  being  added  to  the  lower  action  just  “schedules”  the  arrival 
of  a  train  in  I. 

2.  From  when  the  crossing  becomes  empty,  either  the  time  until  the  gate  is  up  is  bounded  by  ^2  or 
else  the  time  until  a  train  is  in  I  is  bounded  hy  ^2  +  ^  +  Again,  we  express  the  condition  by 
adding  deadlines,  only  this  time  the  situation  is  trickier  since  there  are  two  alternative  bounds 
rather  than  just  one.  We  add  two  new  components,  /as^(up)  and  last/i{I),  both  initially  00. 
The  first  represents  a  milestone  to  be  noted  -  whether  or  not  the  gate  reaches  the  up  position 
by  the  designated  time  -  rather  than  an  actual  deadline.  In  contrast,  the  second  represents 
a  real  deadline  -  a  time  by  which  a  new  train  must  enter  I,  unless  the  gate  reached  the  up 
position  by  the  milestone  time  last2{up).  To  add  these  new  components  to  OpSpec,  we  include 
the  following  additional  effects  in  three  of  the  actions: 

Transitions: 


exit{r) 

Effect: 

if  s.  Trains.r' .status  ^  1  for  all  r'  ^  r  then 
s' .last2{up)  =  nou)-|-  ^2 
s'.lastzif)  =  noui-1-  ^2  -I-  ^  -f 
else 

unchanged  las^(up) 
unchanged  last2{I) 


up 

Effect: 

if  now<  s.last2{up)  then 
s'.last2{up)  =  00 
s'.losfcf/)  =  00 
eke 

unchanged  last2(up) 
unchanged  last2{I) 


enterJ{r) 

Effect: 

s'.last2{up)  =  00 
s'.laskG)  =  00 
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J^so,  as  with  lasti,  an  implicit  precondition  is  placed  on  the  time-passage  action,  saying  that 
time  cannot  pass  beyond  last2{I).  But  no  such  limitation  is  imposed  for  time  passing  beyond 
lasti^up),  because  this  is  just  a  milestone  to  be  recorded,  not  a  time-blockage. 

4.2  Properties 

We  make  some  simple  claims  about  OpSpec: 

Lemma  4.1  In  all  reachable  states  of  OpSpec: 

1.  If  Trains.r. status  =  /  for  any  r,  then  Gate.status  =  down. 

2.  Iast2{up)  -f  ^  -f  =  last2(I). 

Proof:  The  first  property  is  by  definition  of  OpSpec.  The  second  property  is  proved  by  induction 

We  need  only  consider  actions  that  affect  last2iup)  and  last2il),  namely,  up,  enterl(r),  and  exit(r) 
for  some  r.  \  /  v  y 

For  the  action  up,  the  only  case  in  which  the  /astj  components  are  affected  is  where  now  < 
sJasi^iup).  In  this  case,  the  effect  of  up  is  s\last2(up)  =  s'./as<2(/)  =  oo,  and  the  claim  is  satisfied. 

he  effect  of  enterl{r)  is  s  .lastaiup)  =  s' .lastail)  =  oo,  and  thus  the  claim  is  satisfied.  For  exit(r),  the 
only  case  in  which  the  last2  components  are  affected  is  where  r’s  exit  leaves  I  empty.  Then  the  effect 
IS  s  .  ast2{up)  -  now+^2  and  s'.lastiiJ)  =  f*ou;-|-^2  +  ^  +  6>  which  impbes  that  s',/as<2(«p)  +  ^ +  fi  = 
s  .last2{I),  as  needed.  ^ 

Lemma  4.2  In  all  reachable  states  of  OpSpec: 

1.  now  <  lasti. 

2.  now  <  last2{I). 

3.  If  lasti  7^  oo  then  lasti  <  now  +  . 

4-  If  last2(I)  ^  oo  then  last2{I)  <  now  +  ^2  +  ^  +  . 

5.  If  last2{up)  ^  oo  then  last2{up)  <  now-\-^2- 

Proof:  By  induction.  Note  that  the  only  actions  that  can  affect  the  truth  of  1  or  3  are  time  passage 
lower  nnd  enter/ actions,  and  only  time  passage  and  /ouier  actions  could  falsify  1  or  3.  Also,  the  only 
actions  that  can  affect  the  truth  of  2,  4,  or  5  are  time  passage,  exit,  up  and  enter/ actions,’and  only 
time  passage  actions  and  exit  actions  that  leave  /  empty  could  falsify  2,  4  or  5. 

1.  The  precondition  for  time  passage  prevents  s'. now  from  exceeding  s.lasti  =  s'. lasti.  The  effect 

oilower  is  s' .lash  =  nou^  +  6-  By  definition  of  the  constants,  6  >  0,  which  implies  that 
s  .lash  ^  now. 

2.  The  precondition  for  time  passage  prevents  s'. now  from  exceeding  s.last2{I)  =  s'.last2(I).  If 
r’s  exit  leaves  /  empty,  then  an  effect  of  €xit{r)  is  s'.lash{I)  =  noui-f-  6  +  ^  +  6-  By  definition 
of  the  constants,  ^2  +  ^  +  6  >0,  which  implies  that  s'.last2{I)  >  now. 
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3.  If  lower  csiuses  a  change,  then  its  elfect  is  s'.lasti  =  now  +  ^i,  which  implies  s'.lasti  <  now  +  ^i 

as  needed.  For  the  time  passage  action,  suppose  that  s'.lasti  7^  oo-  Since  s.lasti  =  s'.lasti,  we 
have  s.lasti  ^  oo-  Then  by  inductive  hypothesis,  s.lasti  <  s.now  +  ^1.  But  s.now  <  s'. now,  so 
s.now+^i  <  s'  .now  +  ^i.  Therefore,  s'.lasti  ^  as  needed. 

4.  Time  passage  causes  time  to  increase,  so  it  cannot  cause  the  claim  to  be  violated.  For  an  exit{r) 
action  that  leaves  I  empty,  an  effect  is  s'.lasti{I)  =  now +^2  +  ^  +  6?  which  suffices. 

5.  Similar  to  4. 


4.3  Relationship  Between  OpSpec  and  AxSpec 

We  show  that  OpSpec  implements  AxSpec  in  the  following  sense: 

Lemma  4.3  For  any  admissible  timed  execution  a  of  OpSpec,  there  is  an  admissible  timed  execution 
a'  of  AxSpec  such  that  a'|  Trainsx  Gate  =  q:|  Trainsx  Gate.  (This  is  the  same  as  saying  that  a  satisfies 
the  two  properties  given  explicitly  for  AxSpec.) 

We  leave  the  proof  of  Lemma  4.3  to  Appendix  E. 

Note  that  the  relationship  between  OpSpec  and  AxSpec  is  only  one-way:  there  are  admissible 
timed  executions  of  AxSpec  ihsX  have  no  executions  of  0p5pec  yielding  the  same  projection.  Consider, 
for  example,  the  following  example.  Suppose  that  after  /  becomes  empty,  the  system  does  a  very 
rapid  raise,  lower,  raise.  These  could  conceivably  all  happen  within  time  ^2  after  the  previous  time 
there  was  a  train  in  I,  which  would  make  this  “waffling”  behavior  legal  according  to  AxSpec.  However, 
when  this  lower  occurs,  there  is  no  following  entry  of  a  train  into  I,  which  means  that  this  does  not 
satisfy  OpSpec. 

As  a  simple  corollary,  we  obtain: 

Corollary  4.4  attraces{OpSpec)  C  attraces( AxSpec). 

4.4  Proof  Strategy 

The  relationship  between  OpSpec  and  AxSpec  immediately  suggests  a  strategy  for  showing  that 
an  implementation  Systlmpl,  based  on  a  particular  computer  system  implementation  Complmpl, 
satisfies  AxSpec.  The  strategy  is  to  show  that  every  admissible  timed  execution  of  Systlmpl  has  a 
corresponding  admissible  timed  execution  of  OpSpec  that  projects  identically  on  the  Trains  and  Gate 
automata.  Then  use  Lemma  4.3. 

A  simpler  approach,  which  we  use  for  our  example,  is  to  show  that  attraces{SysImpl)  C  attraces(  OpSpec), 
which  implies  by  Corollary  4.4  that  attraces{SysImpt)  C  attrace^ AxSpec).  Then  general  properties 
of  composition  can  be  used  to  infer  the  needed  result. 

5  Implementation 

To  describe  our  implementation  Systlmpl,  we  use  the  same  Trains  and  Gate  automata  but  replace  the 
CompSpec  component  in  OpSpec  and  AxSpec  with  a  new  component  Complmpl,  a  computer  system 
implementation. 
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5.1  Complmpl 

Complmpl  IS  not  an  MMT  automaton  but  a  timed  automaton  with  the  same  interface  as  CompSpec. 
It  keeps  track  of  the  trains  in  R,  together  with  the  earliest  possible  time  that  each  might  enter  I. 

(This  time  could  be  in  the  past.)  It  also  keeps  track  of  the  latest  operation  that  it  has  performed  on 
the  gate  and  the  current  time. 

State; 

for  each  train  r: 

r.status£  {not-herc,  R} ,  initially  not-here 
r.sched-time,  a  nonnegative  real  number  or  oo,  initially  oo 
gate-status^  {up,  down],  initially  up 
now,  initially  0 


Transitions: 

enteri?(r) 

Effect: 

s'. r. status  =  R 
3  .r.sched-time  =  nou)+fi 

exit{r) 

Effect: 

s'. r. status  =  not-here 
s'  .r.sched-time  =  oo 

lower 

Precondition: 

s. gate-status  =  up 

3r  :  s.r.sched-time  <  now-h  +  P 

Effect: 

s'  .gate- status  =  down 


raise 

Precondition: 

s. gate-status  =  down 

flr  :  s.r.sched-time  <  now  +  7tjp  +  ^  +  Idow 
Effect: 

s'. gate- status  :=  up 

v(At) 

Precondition: 
t  =  s.now-f  At 
if  s. gate-status  =  up  then 
f  <  s.r.sched-time- for  all  r 
if  3. gate-status  =  down  then 

3r  :  s.r.sched-time  <  s.now-}-yup  +  «  +  ydown 
Effect: 

s'. now  =  1 


Obser^  that  the  fact  that  Compimpl.gate-status  =  up  does  not  mean  that  Gate.status  =  up  but 
just  that  Gate.status  e  {up,  going-up}.  A  similar  remark  holds  for  Compimpl.gate-status  =  down. 

ote  that  r.sched-time  keeps  track  of  the  earliest  time  that  train  r  might  enter  I.  The  system 
lowers  the  gate  if  the  gate  is  currently  up  (or  going  up)  and  some  train  might  soon  arrive  in  I.  Here 
soon  means  by  the  time  the  computer  system  can  lower  the  gate  plus  a  little  bit  more  -  this  is 
where  we  consider  the  technical  race  condition  mentioned  earlier.  The  system  raises  the  gate  if  the 
gate  IS  currently  down  (or  going  down)  and  no  train  can  soon  arrive  in  I.  This  time,  “soon”  means 
y  e  time  the  gate  can  be  raised  plus  the  time  for  a  car  to  pass  through  the  crossing  plus  the  time 
for  the  system  to  lower  the  gate.  The  system  aUows  time  to  pass  subject  to  two  conditions.  First  if 
gate-status  -  up  then  real  time  is  not  aUowed  to  reach  a  time  at  which  it  is  necessary  to  lower  the 

gate  Second,  if  gate-status  =  down  and  the  gate  should  be  raised,  then  time  cannot  increase  at  aU 
(until  the  gate  is  raised). 

5.2  The  Full  System  Implementation,  Systlmpl 

The  fuU  system  implementation,  Systlmpl,  is  just  the  composition  of  the  Trains,  Gate  and  Complmpl 
components.  ^  ^ 

Here,  we  give  some  useful  basic  invariants  about  Systlmpl;  the  next  two  lemmas  say  that 
LompJmpl  has  accurate  information  about  the  trains  and  gate,  respectively. 
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Lemma  5.1  The  following  are  true  in  any  reachable  state  of  Systlmpl: 

1.  Complmplr. status  —  R  iff  Trains.r. status  £  {-P, /}• 

2.  If  Trains.r. status  =  P,  then  Complmplr.sched-time  =  Trains. firsi{enterl{r)). 

3.  If  Complmpl.r. status  =  R  and  Complmplr.sched-time  >  now,  then  Trains.r. status  =  P. 

4.  If  Trains.r. status  =  I,  then  Complmpl.r. sched-time  <  now. 

5.  If  Complmplr.sched-time  ^  00,  then  Trains.r. status  £  {P,/}. 

Proof;  By  induction. 

1.  The  only  actions  that  can  cause  a  violation  are  actions  that  change  the  truth  values  of  ei¬ 
ther  Complmpl.r. status  =  R  01  Trains.r. status  £  {P,I},  namely,  enterR(r)  and  exitfr).  But, 
enterR{r)  makes  both  sides  of  the  equivalence  true,  and  exit{r)  makes  both  sides  false.  Hence, 
the  property  is  true. 

2.  The  only  actions  that  can  cause  a  violation  are  actions  that  make  Trains.r. status  =  P,  or 
else  change  Complmplr.sched-time  or  Trains. firstf  enter I{t)),  namely,  enterR{r),  exit(r),  and 
enterl(r).  But  exit(r)  and  enterl(r)  cause  Trains.r.status  ^  P,  so  the  claim  is  vacuously 
satisfied.  Further,  the  effect  of  cnfcrP(r)  ensures  that  s'  .Trains.  first(enter^r))  =  now+ei,  and 
s'. Complmplr. sched-time  =  now+€i.  Hence,  s'. Trains. first(enter I(r))  = 

s'  Complmplr.sched-time,  as  required. 

3.  The  only  actions  that  can  cause  a  violation  are  those  that  can  make  Complmpl.r. status  =  R, 
increase  Complmplr.sched-time,  or  make  Trains.r.status  ^  P,  namely,  enterR{r),  exit{r),  and 
enterl{r).  The  effect  of  exit{r)  is  Complmplr. status  ^  R,  and  thus  the  claim  is  vacuously 
satisfied.  The  effect  of  enterR{r)  is  Trains.r. status  =  P,  and  thus  the  claim  is  satisfied. 

Now  consider  enterl{r).  By  the  precondition  of  enterl(r),  s. Trains.r. status  =  P  and  now  > 
s.  Trains. first{enterl{r)).  Part  2  of  this  lemma  implies  that  now  >  s. Complmpl.r. sched-time. 
Since  s. Complmpl.r. sched-time  =  s'  .Complmplr.sched-time,  we  have 
now  >  s'  .Complmplr.sched-time,  and  the  claim  is  vacuously  satisfied. 

4.  Suppose  s'  .Trains.r. status  =  I.  Then  Part  1  implies  that  s'  .Complmplr. status  =  R.  If 
s'  .Complmplr.sched-time  >  s'. now,  then  Part  3  implies  that  s'  .Trains.r. status  =  P,  a  con¬ 
tradiction.  So,  s'  .Complmplr.sched-time  <  s'. now  as  needed. 

5.  The  only  action  that  could  cause  a  violation,  enterR{r),  sets  s'  .Complmplr.sched-time  ^  00. 
In  this  case,  we  have  s'  .Complmplr. status  =  R.  Then  Part  1  implies  s'.  Trains.r.  status  £  {P,/} 
as  needed. 


Lemma  5.2  The  following  are  true  in  any  reachable  state  of  Systlmpl: 

1.  Complmplgate-status  =  up  if  and  only  if  Gate.status  £  {up,  going-up}. 

2.  Complmplgate-status  =  down  if  and  only  if  Gate.status  £  {down,  going-down} . 
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Proof:  By  induction. 


1.  We  need  only  consider  actions  that  change  the  truth  values  of  Compimpl.gate-status  =  up  and 
Gate.statuse  {up,gotng-up},  namely,  lower  und  raise.  For  a  /otcer  action, 

s' .Complmplgate-status  =  down  and  s'.Gate.status  e  {down,going.down},  which  suffices.  For 
s^ffi^el  ■Complmplgate-status  =  up  and  s'.Gate.status  e  {up,  going-up} ,  which  again 

2.  Follows  from  Part  1. 


6  Correctness  Proof 

The  main  correctness  proof  shows  that  every  admissible  execution  of  projects  on  the  external 

world  like  some  admissible  execution  of  OpSpec. 

We  first  prove  a  collection  of  invariants,  leading  to  a  proof  of  the  safety  property.  All  of  the 
invariants  are  proved  by  induction  on  the  length  of  an  execution.  Then  we  give  a  simulation  mapping 
show  the  Utihty  Property.  Technically  speaking,  the  simulation  mapping  only  preserves  timed 
traces,  not  the  coinplete  view  of  the  environment  components.  However,  standard  composition 
techniques  for  timed  automata  show  that  the  view  is  also  preserved. 

6.1  Invariants 

In  this  section,  we  prove  the  main  safety  invariant,  namely:  “H  Trains.r. status  =  I  for  any  r,  then 

Gate.status  =  down.  We  do  this  with  the  help  of  two  preliminary  invariants.  The  first  invariant 

says  that  if  a  tram  is  in  the  region  and  the  gate  is  either  up  or  going  up,  then  the  train  must  stiU  be 
lar  irom  the  crossing. 

Lemma  6.1  In  all  the  reachable  states  of  Systlmpl,  if  Trains.r.status  =  P  and 
Gate.statuse  {up,  going-up} ,  then  Trains.firs^enterlir))  >  now 

Proof:  By  induction.  Fix  nuy  particular  train  r.  We  need  only  consider  actions  that  cause 

T™  ?  to  be  ii>  {tip.poms-up),  decrease 

Trains. first(enterl{r)),  or  increase  now,  namely  enterR{r),  raise,  and  v. 

1.  enter R{r) 

An  effect  is  Mns.firsl(e«UrI(r))  =  „o„+  e,.  Since  e,  >  by  an  assumption  on  the 

constants,  we  have  s  .  Trains. first^enterlir))  >  now-{-  idoww  ^  needed. 

2.  raise 

Assuine  that  s'  Trains.r.status  =  P.  The  precondition  implies  that  s.CompImpl.r.sched-time  > 
now+  7up  +  ^  so  that  s.CompImplr.sched-time  >  now  +  7^  and  therefore 

s.CompIrnpl.r.sched-time>  not.+7rf^^„.  By  Lemma  5.1,  Part  2,  s' .Complmpl.r.sehed-time  = 
s  .Trains.firsi{enterl{r)).  So  s' .Trains.firs1{enterl{r))  >  nou,+  7^^^^,  as  needed. 
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3.  i>{At) 

Assume  s  .Trains.T. status  =  P  and  s'  .Gate. status  6  {^up,  going-up} .  Then,  Lemma  5.2  implies 
that  s' .Complmpl.gate-status  =  up,  and  the  precondition  for  time  passage  implies  that 
s'. now  <  s.CompImpl.r.sched-time  -  Lemma  5.1,  Part  2, 

s.CompImplr.sched-time  =  s. Trains. first(enterl{r)).  So,  s.  Trains. first(enter^r))  >  s'. now + 
‘^doww  implies  s'.  Trains. firsi(enter^r))  >  s'. now as  needed. 


The  second  invariant  says  that  if  a  train  is  nearing  I  and  the  gate  is  going  down,  then  the  gate  is 
nearing  the  down  position.  In  particular,  the  earliest  time  at  which  the  train  might  enter  I  is  strictly 
after  the  latest  time  at  which  the  gate  will  be  down. 

Lemma  6.2  In  all  reachable  states  of  Systlmpl,  if  Trains.r.status  =  P  and 
Gate.status  =  going-down,  then  Trains.first(enterl{r))  >  Gate.lastfdown). 

Proof:  Another  inductive  argument.  Fix  any  particular  trcdn  r.  We  need  only  consider  actions  that 
make  Trains.r.status  =  P  ot  Gate.status  =  going-down,  decrease  Trains.first(enterl{r))  or  increase 
Gate.last(down),  namely,  enterR(r),  lower,  enterl(r),  raise  and  down. 

1.  enter I(r),  raise,  or  down. 

In  each  case,  the  claim  is  vacuously  satisfied. 

2.  enterR(r) 

Assume  s'  .Trains.r. status  =  P  and  s'  .Gate.status  =  going-down.  Then,  Part  2  of  Lemma  B.l 
implies  that  s' .Gate.last(down)  <  now+  The  effect  of  enterR{r)  is 

s' .Trains.first(enterl{r))  =  now-\-€\.  By  an  assumption  about  the  constants,  ti  > 
so  now Cl  >  fioto  +  7(iou;n-  s' .Trains.first{enterl{r))  >  s' .Gate.last{down)  as  needed. 

3.  lower 

Suppose  s'. Trains.r. status  =  P.  We  only  need  to  consider  the  case  where  s. Gate.status  £ 
{up,  going-up},  since  otherwise  the  lower  doesn’t  change  anything.  By  Lemma  6.1,  this  implies 
that  s.  Trains. first{enterl{r))  >  ^ow which  implies  that  s'.  Trains. first(enterl{r))  > 
nou;  +  Since  now-\-  l^own  ~  s' .Gate.last{down),  the  needed  inequality  follows. 


These  invariants  yield  the  main  safety  result: 

Lemma  6.3  In  all  reachable  states  of  Systlmpl,  if  Trains.r. status  =  I  for  any  r,  then  Gate.status  = 
down. 

Proof:  By  induction  again.  This  time,  the  interesting  cases  are  enterl  and  raise.  Fix  r. 
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1.  enterl{r) 

By  the  precondition,  s.  Trains.r. status  =  P. 

If  s.Gate.status  €  {up,  going-up),  then  Lemma  6.1  implies  that  5.  Trains. first{enterl{r))  >  now-\- 
'^dowri-'  s.  Trains. first(enterl(r))  >  now.  But,  the  precondition  for  enterl{r)  is 

s.Trains.first{enterI{r))  <  now.  This  means  that  it  is  impossible  for  this  action  to  occur  a 
contradiction.  ’ 

If  s.Gate.status  =  going-down,  then  Lemma  6.2  implies  that 

s.Trains.first{enterI{r))  >  s.Gate.lastidown).  By  Lemma  B.l,  s.Gate.status  =  going-down 
imphes  s.Gate.lastidown)  >  now.  This  implies  that  s. Trains. jirst{enterl{r))  >  now,  which 
again  means  that  it  is  impossible  for  this  action  to  occur. 

The  only  remaining  case  is  s.Gate.status  =  down.  This  implies  s' .Gate.status  =  down,  which 
suffices. 

2.  raise 

We  need  to  show  that  the  gate  doesn’t  get  raised  when  a  train  is  in  /.  So  suppose  that 
s.Trains.r. status  =  7.  The  precondition  of  raise  states  that  s.CompImpl.r.sched-time  < 
nou;+  7up  +  ^  +  which  implies  that,  for  all  r,  s.CompImpl.r.sched-time  >  now.  But 

Parts  1  and  3  of  Lemma  5.1  imply  that  in  this  case,  s.Trains.r.status  =  P,  a  contradiction. 


6.2  Simulation  Mapping 

Now,  in  order  to  show  the  Utility  Property,  we  present  the  simulation  mapping  from  Systlmpl  to 

OpSpec.  Specifically,  if  s  and  u  are  states  of  SystImpUnd  OpSpec,  respectively,  then  we  define  s  and 
u  to  be  related  by  relation  /  provided  that: 

1.  u.now  =  s.now. 

2.  u.  Trains  =  s.  Trains.'^ 

3.  u.Gate  =  s.Gate. 

4.  u.lasti  >  min{s.Trains.last(enterj^r))}. 

5.  Either  u.last^il)  >  min{s.  Trains. last(enter I (r))},  or 
u.last2{up)  >  now-\-  -yup  and  the  raise  precondition  holds  in  s,  or 
u.last2{up)  >  s.Gate.last{up)  and  s.Gate.status  =  going-up. 

The  first  three  parts  of  the  definition  are  self-explanatory.  The  last  two  parts  provide  connections 
between  the  time  deadUnes  in  the  specification  and  implementation.  In  the  typical  style  for  this 
approach,  the  connections  are  expressed  as  inequalities.  The  fourth  condition  bounds  the  latest  time 
or  some  train  to  enter  I,  a  bound  mentioned  in  the  specification,  in  terms  of  the  actual  time  it  could 
take  in  the  implementation,  namely,  the  minimum  of  the  latest  times  for  all  the  trains  in  P.  The 
fifth  condition  is  slightly  more  complicated  -  it  bounds  the  time  for  either  some  train  to  enter  I  or 

By  this  we  mean  that  the  entire  state  of  the  Train,  automaton,  including  the  time  components,  is  preserved. 
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the  gate  to  reach  the  up  position.  There  are  two  cases  for  the  gate  reaching  the  up  position  -  one  in 
which  the  gate  has  not  yet  begun  to  rise  and  the  other  in  which  it  has. 

Theorem  6.4  /  is  a  simulation  mapping  from  Systlmpl  to  OpSpec. 

Proof:  We  must  show  the  three  conditions  in  the  definition  of  a  simulation  mapping.  The  three 
conditions  are  defined  in  Appendix  C.  The  first  condition,  preservation  of  the  now  value,  is  immediate 
from  the  definition  of  /.  The  second  condition  is  also  immediate,  because  the  unique  start  states  of 
the  two  automata  satisfy  aU  the  relationships  in  the  definition  of  /.  The  interesting  condition  is  the 
step  condition. 

Suppose  that  s  Systlmpl  satisfy  the  invariants  of  Systlmpl,  and  u  €  /[s]  satisfies 

the  invariants  of  OpSpec.  We  must  produce  u'  €  /[s']  such  that  there  is  a  timed  execution  fragment 
from  u  to  u'  having  the  same  timed  visible  actions  as  the  given  step.  We  do  this  using  a  case  analysis 
on  TT. 

For  each  non- time-passage  action  tt,  we  first  argue  that  tt  is  enabled  in  u  and  then  define  u'  to  be 
the  unique  state  that  results  from  applying  the  indicated  action  from  state  u.  For  the  time-passage 
action,  we  first  argue  that  the  same  amount  of  time  can  pass  from  u,  and  then  define  u'  to  be  the 
unique  state  that  results  from  allowing  that  amount  of  time  to  pass. 

Then  in  each  case,  we  must  check  that  u'  €  in  each  case.  Conditions  1-3  are  easy  to  check, 
so  we  need  only  consider  Conditions  4  and  5.  Condition  4  is  also  easy  for  all  cases  except  the  lower 
action,  since  that  is  the  only  action  that  can  decrease  last^.  (The  only  action  that  can  raise  the 
minimum  on  the  right-hand  side  of  the  inequality  is  enter/,  but  that  sets  lasti  to  oo.)  So  we  omit 
mention  of  Condition  4  in  aU  other  cases. 

1.  TT  =  enterR{r). 

Enabling:  Since  tt  is  enabled  in  s,  we  have  s.Trains.r.status  =  not-here.  Since  u  €  f[s],  we  have 
u.  Trains,r. status  =  not-here.  This  implies  that  tt  is  enabled  in  u. 

Condition  5:  The  only  alternative  that  might  be  falsified  by  tt  is  the  second,  and  only  if 
enterR{r)  falsifies  the  raise  precondition.  So  suppose  that  u.last2{up)  >  now  +  7up  and 
the  raise  precondition  holds  in  s  but  gets  falsified  in  s'.  Then,  there  exists  r  such  that 
s' .Complmpl.r.sched-time  <  noiu-f-  7«p  -f  ^  -h  l^own'  Since  an  effect  of  the  action  is 
s' .Complmplr.sched-time  =  nots-f  ei,  we  have  €i  <  7up  -f  ^  -f 

It  suffices  to  show  that  u'.lastq{I)  >  s' .Trains.last{enterl{r)),  since  that  would  show  that  the 
action  makes  the  first  alternative  of  Condition  5  true.  We  have  that  ti'./as^(/)  =  u.last2{I) 
and  s' .Trains.last(enterl{r))  =  now+  €2-  So  it  suffices  to  show  that  u.last2{I)  >  now+  €2. 

Since  u.last2{up)  >  now-\-'iup,  and  u.last2{I)  =  u.last2{up)+6+^i  (this  by  Part  2  of  Lemma  4.1), 
it  is  enough  to  show  that  aou;-|-7up-f^  +  ^i  >  now+e2,  or,  more  simply,  that  7up-|-^-|-^i  >  C2- 

But  7up  +  ^  >  Cl  -  7(/ou;n  as  noted  above.  And  we  have  that  >  'Tdown  +  ^2  -  Ci,  by  an 
assumption  about  the  constants.  So,  7up  +  ^  +  >  62  as  needed. 

2.  TT  =  enterl(r). 

Enabling:  Similar  to  enterRfr). 

Condition  5:  tt  makes  last2{I)  =  00  and  last2{up)  =  00,  which  make  the  condition  trivially 
true. 
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3.  ;r  =  exit{r). 

Enabling:  Similar  to  enterR(r). 

Condition  5: 

There  are  three  cases,  based  on  which  of  the  three  alternatives  becomes  falsified. 

(a)  The  first  alternative  is  falsified. 

Then,  it  must  be  that  tt  decreases  u.last2{I),  and  that  no  train  is  in  I  after  the  step. 

We  have  that  u\last2{I)  =  now+^2+^+^1  and  u'.last2{up)  =  now+^2-  If  the  precondition 
for  mise  holds  after  the  step,  then  it  suffices  to  show  that  u'.last2{up)  >  now+  ')xip-  That 

is,  it  suffices  to  show  that  ^2  >  lup-  But  this  follows  from  an  assumption  about  the 
constants. 

Suppose  that  the  precondition  for  raise  does  not  hold  after  the  step.  Then  there  is  some 
T  such  that  s  .Compimpl.r' .sched-time  <  now+  7^^,  +  ^  (The  first  precondition 

of  raise,  gate-status  =  down,  cannot  fail  after  the  step  because  of  Lemma  6.3  applied 
to  s.)  The  fact  that  s' .Complmplr' .sched-time  00  and  Part  5  of  Lemma  7.1  together 
imply  that  s'.  Trains.r'. status  e  However,  by  assumption,  no  trains  are  in  I  after 

the  step,  so  it  must  be  that  s'.  Trains.r'. status  =  P.  Then  Lemma  5.1,  Part  2,  implies 
that  s  .  Trains. first(enterl(r'))  <  now 7^^  +  ^  +  7(fou;n>  Lemma  3.1  implies 

that  s.Trains.last(enterI{r'))  <  now-i-^up  +  S  +  7dou;n  +  ^2  -  ej.  It  suffices  to  show  that 
u  .lastail)  >  s' .Trains.last{enterl{r')).  To  show  this,  it  suffices  to  show  that  rjoty+^2  +  <5  + 

6  >  nou;+7up+^+7^^y^^+e2-ei,  or,  more  simply,  that  ^2+6  >  lup+1  down+^^-^i.  But 

this  Mows  from  the  inequaUties  6  >  lup  and  6  >  7^^^^  +  ^  +  ^2  _  • 

(b)  The  second  alternative  is  falsified. 

Then  the  raise  precondition  must  be  true  in  s.  By  the  precondition,  s.  Trains.r. status  =  I. 
Then  Lemma  5.1,  Part  4,  implies  that  s. Compimpl.r. sched-time  <  now.  But  this  violates 
the  raise  precondition  in  s,  which  is  a  contradiction. 

(c)  The  third  alternative  is  falsified. 

Then  s.Gate.status  =  going-up.  By  the  precondition,  we  have  s.  Trains.r. status  =  I,  so  by 
Lemma  6.3,  we  have  that  s.Gate.status  =  down,  a  contradiction. 

4.  TT  =  raise. 

Enabling:  Clearly  tt  is  enabled  in  u,  because  OpSpec  imposes  no  preconditions  on  its  perfor¬ 
mance. 

Condition  5:  The  only  alternative  that  can  be  falsified  is  the  second.  Suppose  that 
u.lastaiup)  >  now-f  7„p.  We  have  u'.last2{up)  =  u.lasiziup),  so  u' .last2{up)  >  now->r-iup-  But, 
s  .Gate.last(up)  =  now+n/up  and  s'  .Gate. status  =  going-up,  which  yields  the  third  alternative. 

5.  TT  =  lower. 

Enabling:  As  for  raise. 

The  precondition  for  lower  la  5yst/mp/ implies  that  s.CompImpl. gate- status  =  up  and  that  there 
is  a  particular  r  such  that  s. Complmplr. sched-time  <  notn  +  7^^^^^  +  Then  Lemma  5.2 
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implies  that  s. Gate. status  €  {up,  going-up}.  M s.Trains.r. status  =  /,  then  Lemma  6.3  is  violated 
in  s.  Because  s.CompImpl.r.sched-time  ^  oo,  it  cannot  be  that  s.Trains.r. status  =  not-here. 
So  it  must  be  that  s.  Trains.r. status  =  P. 

Then  Lemma  5.1,  Part  2,  implies  that  s.CompImpl.r.sched-time  =  s.  Trains. first{enterl{r)),  and 
Lemma  3.1  implies  that  s.CompImpl.r.sched-time+  €2  -  ei  =  s.Trains.last(enterI{r)).  Thus,  we 
have  s.  Trains.last{ enterSj))  =  s.CompImpLr.sched-time-\-  C2  —  Ci  ?  <  now+  7 +  /?  +  €2  —  Ci , 
<  noin+^i  by  an  assumption  about  the  constants.  That  is,  nou>+^i  >  s.Trains.last{enterI{r)). 

Condition  4:  By  definition  of  lower  in  OpSpec,  u'.lastx  =  now  +  (i.  But  as  we  showed  above, 
this  is  at  least  as  great  as  s.Trains.lasi(enterI(r))  =  s' .Trains.last{enterl{r)).  That  is,  u'.lasti  > 
s' .Trains.last{enter]{r)),  as  needed. 

Condition  5:  The  only  alternative  that  tt  can  falsify  is  the  third.  So  suppose  that  u.last2{up)  > 
s.Gate.last{up)  and  s.Gate.status  =  going-up.  Lemma  B.l  implies  that  s.Gate.last{up)  >  now, 
so  u.last2{up)  >  now.  Since  u.last2(up)  =  u' .last2{up),  we  have  u' .last2(up)  >  now. 

Then  Lemma  4.1  implies  that  u'.lasliil)  =  u'.last2{up)  +  6  +  which  is  in  turn  >  nou;  +  ^1. 
Since  noin  +  ^1  >  s. Trains. last{enterl{r)),  we  have  u'.last2(I)  >  s.Trains.last{enterl{r)),  so 
u' .lasta^I)  >  s'  .Trains.  last(enterl[^r)).  This  suffices  for  alternative  1. 

6.  T  =  up. 

Enabling:  Similar  to  enterR. 

Condition  5:  Because  tt  doesn’t  decrease  any  of  the  left  sides  of  the  inequalities,  it  cannot 
falsify  alternative  1.  Alternative  2  can’t  hold  before  the  step,  because  the  raise  precondition 
and  the  up  precondition  are  exclusive.  Suppose  that  tt  falsifies  alternative  3.  Then  u.lastz^up)  > 
s.Gate.last{up)  and  s.Gate.status  =  going-up.  Lemma  B.l  implies  that  s.Gate.last{up)  >  now, 
so  u.last2(up)  >  now.  But  then  the  effect  of  the  action  implies  that  u'.lastail)  =  00,  which 
suffices  to  satisfy  alternative  1. 

7.  X  =  down. 

Enabling:  Similar  to  enterR. 

Condition  5:  Straightforward. 

8.  X  =  i/{At). 

Enabling:  We  must  show  that  time  At  is  allowed  to  pass  in  OpSpec.  This  amounts  to  showing 
that  s'. now  <  u.lasti  and  s'. now  <  u.last2{I). 

To  show  s'. now  <  u.lasti,  we  only  need  to  consider  the  case  where  u.lasti  ^  00.  la  this  case. 
Condition  4  implies  that  u.lasti  >  s.Trains.last{enterI{r)')  for  some  r.  The  precondition  on 
time-passage  in  Complmpl  implies  that 

s'. now  <  s.Trains.last{enterI(^r)).  So  s'. now  <  u.lasti,  needed. 

To  show  that  s'. now  <  u.lasta{I),  we  only  need  to  consider  the  case  where  u.last2{I)  ^  00.  In 
this  case,  we  consider  the  three  alternatives,  for  s  and  u.  If  the  first  alternative  holds,  then  the 
argument  is  as  for  lasti.  If  the  second  alternative  holds,  then  the  raise  precondition  holds  in  s. 
But  this  implies  that  1/  cannot  be  enabled  in  s,  a  contradiction.  If  the  third  alternative  holds, 
then  s'. now  <  s.Gate.last{up)  <  u.last2{up)  <  u.last2{I),  which  suffices. 
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Condition  5:  The  only  alternative  that  the  time-passage  action  might  falsify  is  the  second.  But 

this  means  that  the  raise  precondition  holds  in  s,  which  is  impossible  since  then  v  could  not 
be  enabled  in  s. 


6.3  Putting  the  Pieces  Together 

Now  we  can  put  the  pieces  together  to  obtain  our  main  correctness  result.  The  simulation  result 
immediately  implies  that  all  admissible  timed  traces  of  Syslmpl  are  admissible  timed  traces  of  OpSpec 
bee  Appendix  A  for  the  notation. 

Lemma  6.5  attraces{SysImpI)  C  attraces{OpSp€c). 

Proof:  By  Theorem  6.4  and  Theorem  C.l.  ^ 

Thus  we  have: 


Corollary  6.6  attraces(SysImp[)  C  attraces( OpSpec). 

Proof:  By  Lemma  6.5  and  Corollary  4.4.  ^ 

This  is  not  quite  what  we  need,  because  it  does  not  give  us  corresponding  projections  on  the 
environment  automata.  However,  we  can  obtain  the  main  theorem  using  general  results  about 
composition  of  timed  automata: 


Theorem  6.7  For  any  admissible  timed  execution  a  of  Systlmpl,  there  is  an  admissible  timed  exe¬ 
cution  a  of  AxSpec  such  that  q'(  Trains  x  Gate  =  q|  Trains  x  Gate. 


Proof:  Let  q  be  any  admissible  timed  execution  of  Syslmpl  and  let  6  =  ttrace(a).  Lemma  A  2 
imphes  that  a\E  €  atexecs{E).  Then  CoroUary  6.6  yields  an  admissible  timed  execution  /?  of  AxSpec 
such  that  ttracei^  -  ttrace{a)  =  6.  Note  that  /?  satisfies  the  Safety  and  Utility  properties.  Also 
Lemma  A.2  implies  that  /3\CompSpec  E  atexces(CompSp€c).  ' 

Now  we  define  a  new  admissible  timed  execution  q'  of  the  system  composed  of  E  and  CompSpec. 
Since  ttrace{a\E)  and  6\CompSpec  =  ttrace{0\CompSpec),  Lemma  A.3  implies  that  there  is 

an  admissible  timed  execution  a'  of  the  system  composed  of  E  and  CompSpec  such  that  a'\E  =  a\E 

and  a  \CompSpec  =  l3\CompSpec.  Note  that  ttrace{a')  =  6,  because  all  actions  are  in  the  interface 

01  Jb, 


We  claim  that  a  satisfies  the  required  properties.  First,  a'  is  defined  to  be  an  admissible  timed 
execution  of  the  system  composed  off;  and  CompSpec,  to  see  that  it  is  an  admissible  timed  execution 
o  xS^c  It  suffices  to  show  that  it  satisfies  the  Safety  and  Utility  properties.  But  this  foUows  from 
the  facts  that  ttrace{a  )  =  S=  ttrace{P)  and  that  fd  satisfies  the  Safety  and  Utility  properties  (These 
properties  can  be  inferred  from  the  timed  traces.)  Second,  a>\E  =  a\E  by  construction.  This  is  as 
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7  Realistic  Models  of  the  Real  World 


The  models  used  above  for  the  trains  and  gate  are  rather  abstract.  An  applications  expert  might 
prefer  more  realistic  models,  giving,  for  instance,  exact  or  approximate  positions  for  the  trains  and 
gate.  However,  a  formal  methods  expert  would  probably  not  want  to  include  such  details,  because 
they  would  complicate  the  proofs.  Fortunately,  we  can  satisfy  everyone. 

It  is  possible  to  define  a  pair  of  models  for  any  real  world  component,  one  abstract  and  one 
more  realistic.  The  only  constraint  is  that  the  realistic  model  should  be  an  “implementation”  of 
the  abstract  model,  i.e.,  its  set  of  admissible  timed  traces  should  be  included  in  that  of  the  abstract 
model.  All  the  difficult  proofs  are  carried  out  using  the  abstract  models,  as  above.  Then  corollaries 
are  given  to  extend  the  results  to  the  realistic  models.  This  extension  is  based  on  general  results 
about  composition  of  timed  automata. 

For  example,  we  can  define  a  new  type  of  gate  component.  Gate',  similar  to  the  Gate  defined 
above,  but  having  a  more  detailed  model  of  gate  position.  Gate'  is  also  a  timed  automaton.  Fix 
any  constant  T^ot^n’  ®  -  '^'down  -  '^down-  define  gd  to  be  a  function  mapping  [0,7^/ J  [^,90]. 
Function  gd  is  defined  so  that  ^^(0)  =  90,  ~  monotone  nonincrea^ing  and 

continuous.  gd(t)  gives  the  position  of  the  gate  after  it  has  been  going  down  for  time  t.  Similarly,  fix 
a  constant  Yupr  0  ^  7up  ^  7upj  define  to  be  a  function  mapping  [0,7^^]  to  [0,90].  Function 
gu  is  defined  so  that  5u(0)  =  0,  guil'up)  —  90^  3'®^  9u  is  monotone  nondecreasing  and  continuous. 

The  actions  of  Gate'  are  the  same  as  for  Gate.  The  state  is  also  the  same,  with  the  addition  of 
one  new  component  pos  €  [0, 90]  to  represent  the  gate  position,  initially  90: 

State: 

<tatu4  in  {up,  down,  going-up,  going-down^,  initially  up 

pos  €  [0, 90],  initially  90 

now,  a  nonnegative  real,  initially  0 

last(down),  a  nonnegative  real  or  oo,  initially  oo 

last{up),  a  nonnegative  real  or  oo,  initially  oo 


The  transitions  are  as  follows.  The  lower  and  raise  transitions  are  the  same  as  for  Gate,  except 
that  «tnd  7up  are  used  in  place  of  7«p-  down  transitions  contains 

new  preconditions  stating  that  the  correct  position  has  been  reached.  The  time-passage  transitions 
adjust  pos. 
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Transitions; 


lower 

Effect: 

if  s. status  £  {up,  going-up]  then 
s'  .status  =  going-down 
s'  .last(down)  =  now  + 
s'.last(up)  =  oo 

else  unchanged  status,  last{down),  last(up) 


Precondition: 

s. status  =  going-up 
s.pos  =  90 
Effect: 

s'. status  =  up 
s'.last(up)  =  oo 


raise 

Effect: 

if  s. status  £  [down,  going-down]  then 
s  .status  =  going-up 
s' .last{up)  =  nou'+  I'up 
s'  .last(down)  =  oo 

else  unchanged  status,  last{down),  last(up) 

down 

Precondition: 

s. status  =  going-down 
s.pos  =  0 
Effect: 

s'  .status  =  down 
s'  .last{down)  =  oo 


./(Ai) 

Precondition: 
t  =  noir  +  At 
t  <  s.last(down) 
i  <  s.last(up) 

Effect: 

s'. now  =  1 

if  s. status  =  going-up  then 
s'.po4=inax{s.po5,  5u(t— (s-/as<(tip)  — 7op))} 
elseif  s. status  =  going-down  then 
s'.po»= min  {s.pos,  gd{t-{s.last{ down)  -  'tJg^^„))] 
else  unchanged  pos 


Thus,  unlike  the  more  abstract  automata  considered  so  far,  Gate'  allows  interesting  state  changes 
to  occur  in  conjunction  with  time-passage  actions.  Note  that  Gate'  contains  a  rather  arbitrary 
decision  about  what  happens  if  a  lower  event  occurs  when  the  gate  is  in  an  intermediate  position. 
It  says  that  the  gate  stays  stiU  for  the  initial  time  that  it  would  take  for  the  gate  to  move  down  to 
its  current  position  if  it  had  started  from  position  0.  Alternative  modeling  choices  would  also  be 
possible.  A  similar  remark  holds  for  raise. 

One  detail  needs  mentioning:  we  need  to  verify  that  when  we  apply  the  functions  and  gj  to 
arguments  in  the  time-passage  transitions,  the  arguments  are  in  fact  within  the  specified  interval.  For 
example,  consider  the  application  gu{t  —  {s.last{up)  —  ,  which  occurs  when  s. status  =  going-up. 

We  must  be  sure  that  0  <  /  —  {s.last(up)  —  7^^)  <  7^^,.  The  first  inequality  follows  from  the  facts 
that  s.last(up)  <  s.now-i-  "y'up  ^'Hd  s.now  <  t,  while  the  second  inequality  follows  from  the  fact  that 
t  <  s.last{up). 

We  relate  the  new  gate  model  to  the  old  one. 


Lemma  7.1  attraces{Gate')  C  attraces{Gate). 

Proof:  By  Theorem  C.l,  it  suffices  to  show  the  existence  of  a  simulation  mapping  from  Gate'  to 
Gate.  If  s  and  u  are  states  of  Gate'  and  Gate,  respectively,  then  we  define  s  and  u  to  be  related  by 
relation  /  provided  that; 


1.  u. status  =  s. status. 

2.  u.now  =  s.now. 

3.  u.last(down)  >  s.last{down). 
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4.  u.last{up)  >  s.last(up). 

It  is  straightforward  to  show  that  /  is  a  simulation  mapping.  ■ 

Now,  let  SystImpV  be  the  composition  of  Trains,  Gate!,  and  Complmpl,  and  let  AxSped  be  the 
composition  of  Trains,  Gate',  and  CompSpec,  with  Safety  and  Utility  Properties  added  as  in  AxSpec. 
Using  Theorem  6.7  and  general  results  about  composition  of  timed  automata,  we  obtain: 

Theorem  7.2  For  any  admissible  timed  execution  a'  of  SystImpV,  there  is  an  admissible  timed 
execution  /?'  of  AxSped  such  that  a'|  Trains  x  Gate'  =  ^'\  Trains  x  Gate'. 

Proof:  We  define  two  environment  automata:  let  E  be  the  composition  of  Gate  and  Trains,  and  E' 
the  composition  of  Gate'  and  Trains.  Lemma  7.1  says  that  attraces(Gatd)  C  attraces(Gate).  This  and 
a  basic  substitutivity  property  of  composition.  Lemma  A.l,  imply  that  attraces{E')  C  attraces{E). 
Let  a'  be  any  admissible  timed  execution  of  SystImpV,  and  let  6  =  ttrace(a'). 

Lemma  A. 2  implies  that  a'\E'  €  atexecs(E')  and  a'\CompImpl  £  atexecs( Complmpl).  Since 
attraces{E')  C  attraces{E),  we  may  obtain  7  €  atexecs{E)  with  ttrace{'))  =  ttrace(a'\E')  = 
ttrace{a')\E'  =  6\E'  =  6. 

Now  we  construct  an  admissible  timed  execution  a  of  Systimpl.  Since  b\E  =  ttrace{'y)  and 
6\CompImpl  =  ttrace[Q'\CompImpl),  Lemma  A.3  implies  that  there  is  an  admissible  timed  execution 
a  of  Systimpl  such  that  q\E  =  7  and  a\CompImpl  =  a'\CompImpl.  We  have  that  ttrace{a)  = 
ttrace('y)  =  6. 

Next,  by  Theorem  6.7  applied  to  a,  we  obtain  an  admissible  timed  execution  /?  of  AxSpec  such 
that  f3\E  =  q\E.  It  follows  that  ttrace(l3)  =  ttrace{a)  =  6  and  that  /?  satisfies  the  Safety  and  Utility 
properties. 

Now  we  define  an  admissible  timed  execution  /?'  of  the  system  composed  of  E'  and  CompSpec. 
Since  6\E'  —  ttrace{Q'\E')  and  6\CompSpec  —  ttrace{p\CompSpec),  Lemma  A.3  implies  that  there  is 
an  admissible  timed  execution  S'  of  the  system  composed  of  E'  and  CompSpec  such  that  S'\E'  =  ci'\E' 
and  S'\CompSp€c  =  S\CompSpec.  Note  that  ttrace(S')  =  6. 

We  claim  that  S'  satisfies  the  required  properties.  First,  S'  is  defined  to  be  an  admissible  timed 
execution  of  the  system  composed  of  E'  and  CompSpec,  to  see  that  it  is  an  admissible  timed  execution 
of  AxSped  it  suffices  to  show  that  it  satisfies  the  Safety  and  Utility  properties.  But  this  follows  from 
the  facts  that  ttrace{S')  =  S  =  ttrace{S)  and  that  S  satisfies  the  Safety  and  Utility  properties.  (These 
properties  can  be  inferred  from  the  timed  traces.)  Second,  S'\E'  =  a'\E'  by  construction.  This  is  as 
needed.  H 

8  Discussion 

We  have  applied  a  formal  method  based  on  timed  automata,  invariants,  and  simulation  mappings 
to  model  and  verify  the  Generalized  Railroad  Crossing  example  [7].  Here,  we  extrapolate  from  this 
experience  and  attempt  to  evaluate  the  method  for  use  in  modeling  and  verifying  other  real-time 
systems.  We  also  describe  future  work. 

•  Generality.  Can  the  method  be  used  to  describe  all  acceptable  implementations?  It  seems 
so.  For  instance,  timed  automata  can  have  an  infinite  number  of  states  and  both  discrete  and 
continuous  variables.  Further,  they  can  express  the  maximum  allowable  nondeterminism,  use 
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symbolic  parameters  to  represent  system  constants,  and  represent  asynchronous  communica¬ 
tion.  Thus  the  method  is  significantly  more  general  than  approaches  based  on  model-checking, 
which  typically  require  a  finite  number  of  states  and  constant  timing  parameters. 

•  Readability.  Are  the  formal  descriptions  easy  to  understand?  The  environment  model  and 
the  system  implementation  model  are  easy  to  understand,  since  it  is  natural  to  model  these  as 
automata.  The  requirements  specifications  do  not  look  so  natural  when  expressed  as  automata; 
an  axiomatic  form  seems  easier  to  understand.  However,  if  one  starts  with  an  axiomatic 
specification,  then  one  has  to  rewrite  the  specification  as  an  automaton.  It  may  be  difficult 
to  determine  that  the  automaton  specification  is  equivalent  to  (or  implements)  the  axiomatic 
specification. 

•  Power.  Can  the  method  be  used  to  verify  all  implementations?  Simulation  methods  (extended 
beyond  what  is  described  in  this  paper,  to  include  “backward”  as  weU  as  “forward”  simulations) 
are  theoretically  complete  for  showing  admissible  timed  trace  inclusion.  They  also  seem  to  be 
powerful  in  practice,  although  they  might  sometimes  benefit  from  combination  with  other 
verification  methods,  such  as  model- checking,  process  algebra,  temporal  logic  or  partial  order 
techniques.  Model- checking  alone  is  less  powerful  in  practice,  since  it  only  checks  whether  a 
subfamily  of  solutions  satisfy  some  specific  properties. 

•  Ease  of  Carrying  out  the  Proof.  How  hard  is  it  to  construct  a  proof  using  this  method? 
Can  typical  engineers  learn  to  do  this? 

Constructing  these  proofs,  though  not  difficult,  required  significant  work.  The  hardest  parts 
were  ptting  the  details  of  the  models  right  and  finding  the  right  invariants  and  simulation 
mapping.  This  is  an  art  rather  than  an  automatic  procedure.  The  actual  proofs  of  the  invariants 
and  the  simulation  were  tedious  but  routine. 

Carrying  out  such  a  modeling  and  verification  effort  requires  the  ability  to  do  formal  proofs, 
which  most  engineers  are  not  trained  to  do.  In  contrast,  using  model- checking,  an  engineer 
can  check  automatically  whether  a  given  “model”  satisfies  the  properties  of  interest.  (Model 
checkers  are  already  being  used  in  practice  by  engineers  to  check  the  correctness  of  certain 
implementations,  e.g.,  of  circuits.)  On  the  other  hand,  the  proofs  developed  using  the  method 
of  this  paper  are  amenable  to  mechanical  proof  checking.  So,  automated  support  can  be 
provided  to  engineers  attempting  to  develop  formal  proofs. 

•  Information.  Does  the  proof  yield  information  other  than  just  the  fact  that  the  implemen¬ 
tation  is  correct?  Does  it  give  any  insight  into  the  reasons  that  the  implementation  works? 
Yes.  The  invariants  and  simulations  that  require  considerable  effort  to  produce  yield  payoffs 
by  providing  very  useful  documentation.  They  express  key  insights  about  the  behavior  of 
the  inaplementation.  In  contrast,  model-checking  methods  yield  no  such  byproducts,  only  an 
assertion  that  the  implementation  satisfies  the  desired  properties. 

•  Scalability.  Does  the  formalism  scale  up  to  handle  larger  problems?  We  don’t  yet  know.  Just 
reasoning  about  this  relatively  simple  problem  was  quite  complex.  A  bigger  system  will  mainly 
add  complexity  in  the  form  of  more  system  components  and  more  actions,  which  leads  in  turn 
to  more  invariants,  more  components  in  the  simulation  mapping,  and  more  cases  in  the  proofs. 
But,  in  contrast  to  model-checking,  the  blowup  should  not  be  exponential.  Nonetheless,  use 
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of  the  method  for  larger  problems  should  be  coupled  with  various  methods  of  decomposing  a 
problem  so  one  need  not  reason  about  an  entire  complex  system  at  once.  Additional  levels  of 
abstraction  and  use  of  parallel  composition  should  help. 

•  Ease  of  Change.  How  easy  is  it  to  modify  the  specifications  and  the  proofs?  Separating 
the  sptem  model  from  the  environment  model  and  splitting  the  environment  model  into  the 
individual  gate  model  and  train  model  makes  it  easy  to  change  the  descriptions.  Should  one 
want  to  use  a  more  complex  train  model  (for  example,  trains  move  backward  as  well  as  forward), 
one  can  easily  substitute  the  revised  model  for  the  original.  Expressing  the  required  properties 
axiomatically  and  independently  makes  it  easier  to  change  the  requirements. 

Changes  to  the  specifications  and  implementations  require,  of  course,  changes  to  the  proofs. 
If  the  changes  are  fairly  small,  however,  we  expect  most  of  the  prior  work  to  survive,  and  the 
stylized  form  of  the  proof  provides  useful  structure  for  managing  the  modifications.  Here  is  a 
place  where  mechanical  aid  would  be  most  helpful  —  proofs  could  be  rerun  quickly  to  discover 
which  parts  need  to  be  changed. 


Future  work  includes; 

1.  Trying  this  method  out  on  larger  examples  from  real-time  process  control  and  timing-based 
communication.  In  the  real-time  process  control  area,  transportation  problems  are  especially 
interesting  to  us.  Some  new  complications  are  expected  to  arise  when  the  continuous  quantities 
of  interest  include  velocity  and  acceleration  as  well  as  time  and  position. 

2.  Developing  the  appropriate  computer  assistance  for  carrying  out  and  checking  the  proofs.  We 
plan  to  try  to  use  the  proof  systems  PVS  [18]  and  Larch  [4]  to  check  the  proofs  and  to  assess 
the  utility  of  mechanical  proof  systems  for  such  proofs. 

3.  Trying  to  systematize  the  reasoning  about  the  correspondence  between  the  axiomatic  and 
operational  specifications. 
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A  The  Timed  Automaton  Model 

This  section  contains  the  formal  definitions  for  the  timed  automaton  model,  taken  from  [14], 

A.l  Timed  Automata 

A  timed  automaton  A  consists  of  a  set  states(A)  of  states,  a  nonempty  set  start{A)  C  stat€s{A)  of 
start  states,  a  set  acts{A)  of  actions,  including  a  special  time-passage  action  v,  a  set  steps{A)  of  steps 
(transitions),  and  a  mapping  uowa  :  states  {R>^  denotes  the  nonnegative  reals.)  The  actions 

are  partitioned  into  external  and  internal  actions,  where  v  is  considered  external;  the  visible  actions 
are  the  non-i/  external  actions;  the  visible  actions  are  partitioned  into  input  and  output  actions. 
The  set  steps{A)  is  a  subset  of  states{A)  x  acts(A)  x  states{A).  We  write  5-2.^  5'  as  shorthand 
for  (s,  7r,s')  €  steps(A),  and  usually  write  s.nowA  in  place  of  nouj^(s).  We  sometimes  suppress  the 
subscript  or  argument  A. 

A  timed  automaton  must  satisfy  five  axioms:  [Al]  If  s  6  start  then  s.now  =  0.  [A2]  If  s  s'  and 
TT  ^  1/  then  s.now  =  s'. now.  [A3]  If  s  s'  then  s.now  <  s'. now.  [A4]  If  s  s"  and  s"  ^  s',  then 
s  »■  s'.  Axiom  [Al]  says  that  the  current  time  is  always  0  in  a  start  state.  Axiom  [A2]  says  that 
non-time-passage  steps  do  not  change  the  time;  that  is,  they  occur  “instantaneously”,  at  a  single 
point  in  time.  Axiom  [A3]  says  that  time-passage  steps  must  cause  the  time  to  increase;  this  is  a 

convenient  technical  restriction.  Axiom  [A4]  allows  repeated  time-passage  steps  to  be  combined  into 
one  step. 

The  statement  of  [A5]  requires  the  preliminary  definition  of  a  trajectory,  which  describes  re- 
strictions  on  the  state  changes  that  can  occur  during  time-passage.  Namely,  if  I  is  any  interval  of 
R  ,  then  an  I-trajectory  is  a  function  w  :  I  ^  states,  such  that  w{t).now  =  t  for  all  <  €  /,  and 
u'C^i)^  w(<2)  for  all  ti,t2  €  /  with  ti  <  t^.  That  is,  w  assigns,  to  each  time  t  in  interval  I,  a 
state  having  the  given  time  t  as  its  now  component.  This  assignment  is  done  in  such  a  way  that 
time-passage  steps  can  span  between  any  pair  of  states  in  the  range  of  w.  If  w  is  an  /-trajectory  and  / 
is  left-closed,  then  define  w.ftime  =  min{I)  and  w.fstate  =  w{w.ftime),  while  if  /  is  right-closed,  then 
define  w.ltime  =  max{I)  and  w.lstate  =  w{w.ltime).  If  /  is  a  closed  interval,  then  an  /-trajectory  w 
IS  s^aid^to  span  from  state  s  to  state  s'  if  w.fstate  =  s  and  w.lstate  =  s'.  The  final  axiom  is:  [A5]  If 
s  s'  then  there  exists  a  trajectory  that  spans  from  s  to  s'.  Axiom  [A5]  is  a  kind  of  converse  to 

[A4];  It  says  that  any  time-passage  step  can  be  “fiUed  in”  with  states  for  each  intervening  time  in  a 
“consistent”  way.  ’ 

A. 2  Timed  Executions  and  Timed  Traces 

A  timed  execution  fragment  is  a  finite  or  infinite  alternating  sequence  a  =  u;o7rii(;i7r2ty2  •  •  •,  where: 

1.  Each  Wj  is  a  trajectory  and  each  kj  is  a  non-time-passage  action. 

2.  If  Q  is  a  finite  sequence,  then  it  ends  with  a  trajectory. 

3.  If  Wj  is  not  the  last  trajectory  in  q  then  its  domain  is  a  closed  interval.  If  Wj  is  the  last 
trajectory  then  its  domain  is  left-closed  (and  either  right-open  or  right-closed). 

4.  If  Wj  is  not  the  last  trajectory  then  Wj.lstate'^  Wj+i.fstate. 
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The  trajectories  describe  the  changes  of  state  during  the  time-passage  steps.  The  last  item  says 
that  the  actions  in  a  span  between  successive  trajectories.  A  timed  execution  is  a  timed  execution 
fragment  for  which  the  first  state  of  the  first  trajectory,  Wq,  is  a  start  state.  In  this  paper,  we  restrict 
attention  to  the  admissible  timed  executions,  i.e.,  those  in  which  the  now  values  occurring  in  the 
states  approach  oo.  We  use  the  notation  atexecs(A)  for  the  set  of  admissible  timed  executions  of 
timed  automaton  A.  A  state  of  a  timed  automaton  is  defined  to  be  reachable  if  it  is  the  final  state 
of  the  final  trajectory  in  some  finite  timed  execution  of  the  automaton. 

In  order  to  describe  the  problems  to  be  solved  by  timed  automata,  we  require  a  definition  for  their 
visible  behavior.  We  use  the  notion  of  timed  traces,  where  the  timed  trace  of  any  timed  execution 
is  just  the  sequence  of  visible  events  that  occur  in  the  timed  execution,  paired  with  their  times  of 
occurrence.  The  admissible  timed  traces  of  the  timed  automaton  are  just  the  timed  traces  that  arise 
from  aU  the  admissible  timed  executions.  We  use  the  notation  attraces{A)  for  the  set  of  admissible 
timed  traces  of  timed  automaton  A.  Often,  we  express  requirements  to  be  satisfied  by  a  timed 
automaton  A  as  the  set  of  admissible  timed  traces  of  another  timed  automaton  B.  Then  we  say 
that  A  implements  B  if  attraces{A)  C  attraces{B).  K  a  is  any  timed  execution,  we  use  the  notation 
ttrace{a)  to  denote  the  timed  trace  of  a. 

We  define  a  function  time  that  maps  any  non-time-passage  event  in  an  execution  to  the  real  time 
at  which  it  occurs.  Namely,  let  tt  be  any  non-time-passage  event.  If  tt  occurs  in  state  s,  then  define 
time{Tr)  =  s.now. 

A. 3  Composition 

We  define  a  simple  binary  parallel  composition  operator  for  timed  automata.  Let  A  and  B  be 
timed  automata  satisfying  the  following  compatibility  conditions:  A  and  B  have  no  output  actions 
in  common,  and  no  internal  action  of  A  is  an  action  of  B,  and  vice  versa.  Then  the  composition  of 
A  and  B,  written  as  A  x  is  the  timed  automaton  defined  as  follows. 

•  states{A  x  B)  =  {(5/i,Sfl)  €  states(A)  x  states{B)  :  s^-nowA  =  ss-nows}', 

•  start{A  X  B)  =  start{A)  x  start{B); 

•  acts{A  X  B)  =  acts{A)  U  ac<s(5);  an  action  is  external  in  A  x  B  exactly  if  it  is  external  in 
either  A  or  B,  and  likewise  for  internal  actions;  a  visible  action  of  A  x  5  is  an  output  in  AxB 
exactly  if  it  is  an  output  in  either  A  or  B,  and  is  an  input  otherwise; 

•  {sa,sb) — *AxB  {s'A^Sg)  exactly  if 

1.  Syi  -^A  if  TT  G  act^A),  else  and 

2.  SB  —^B  Sg  if  TT  €  acts{B),  else  sjg  =  s^; 

•  {sA,SB).nowAxB  =  SA.noWA. 

Then  A  x  5  is  a  timed  automaton.  If  a  is  a  timed  execution  of  A  x  5,  we  write  a|A  and  a\B  for  the 
projections  of  q  on  A  and  B,  respectively.  For  instance,  a\A  is  defined  by  projecting  all  states  in  a 
on  the  state  of  A,  removing  actions  that  do  not  belong  to  A,  and  collapsing  consecutive  trajectories. 
We  also  use  the  projection  notation  for  sequences  of  actions,  writing,  e.g.,  I3\A  for  the  subsequence 
of  13  consisting  of  actions  of  A. 
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Lemma  A.l  (Substitutivity)  Let  A  and  B  be  timed  automata  with  the  same  input  and  output  ac¬ 
tions,  and  let  C  be  a  timed  automaton  compatible  with  both.  If  attraces{A)  C  attraces{B)  then 
attraces(A  x  C)  C  attraces{B  x  C). 

Lemma  A. 2  //a  G  atexecs{A  x  B)  then  a\A  e  atexecs{A)  and  a\B  e  atexecs{B). 

Lemma  A. 3  Suppose  that  €  atexecs{A)  and  as  €  atexecs(B).  Suppose  (3  is  a  sequence  of 
timed  visible  actions  of  Ax  B  such  that  S\A  =  ttrace{aA)  and  S\B  =  ttrace{aB).  Then  there  exists 
a  e  atexecs{A  x  B)  such  that  a\A  =  a  a  and  a\B  =  05. 

Since  the  composition  operation  is  associative,  up  to  isomorphism,  we  may  extend  it  to  an 
arbitrary  finite  number  of  argument  timed  automata. 
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B  MMT  Automata 

B.l  Automaton  Definition 

MMT  automata  were  originally  defined  by  Merritt,  Modugno  and  Tuttle  [17];  we  use  a  special 
case  of  their  definition  from  [12,  14].  An  MMT  automaton  is  an  I/O  automaton  [13]  together 
with  upper  and  lower  bounds  on  time.  An  I/O  automaton  A  consists  of  a  set  states(A)  of  states, 
a  nonempty  set  start{A)  C  states{A)  of  start  states,  a  set  acts(A)  of  actions,  (partitioned  into 
external  and  internal  actions;  the  external  actions  are  further  partitioned  into  input  and  output 
actions),  a  set  steps(^A)  of  steps,  and  a  partition  partf^A)  of  the  locally  controlled  (i.e.,  output  and 
internal)  actions  into  at  most  countably  many  equivalence  classes.  The  set  steps(A)  is  a  subset  of 
states{A)  x  ac<s(A)  x  states^A)]  An  action  t  is  said  to  be  enabled  in  a  state  s  provided  that  there 
exists  a  state  s'  such  that  (s,jr,s')  €  steps(A),  i.e.,  such  that  s — ^^4  s'.  A  set  of  actions  is  said  to 
be  enabled  in  s  provided  that  at  least  one  action  in  that  set  is  enabled  in  s.  It  is  required  that 
the  automaton  be  input-enabled,  by  which  is  meant  that  tt  is  enabled  in  s  for  every  state  s  and 
input  action  tt.  The  final  component,  part,  is  sometimes  called  the  task  partition.  Each  class  in  this 
partition  groups  together  actions  that  are  supposed  to  be  part  of  the  same  “task”. 

An  MMT  automaton  is  obtained  by  augmenting  an  I/O  automaton  with  certain  upper  and  lower 
time  bound  information.  Let  A  be  an  I/O  automaton  with  only  finitely  many  partition  classes.  For 
each  class  C,  define  lower  and  upper  time  bounds,  lower{C)  and  upper{C),  where  0  <  lower(C)  <  00 
and  0  <  upperl^C)  <  00;  that  is,  the  lower  bounds  cannot  be  infinite  and  the  upper  bounds  cannot 
be  0. 


B.2  Timed  Executions  and  Timed  Traces 

A  timed  execution  of  an  MMT  automaton  A  is  defined  to  be  an  alternating  sequence  of  the  form 
(^i» ^i)?  ^1?  •  •  •  where  the  jt’s  are  input,  output  or  internal  actions  (but  not  time-passage  actions). 
For  each  j ,  it  must  be  that  Sj  ^j+i  •  The  successive  times  are  nondecreasing,  and  are  required 
to  satisfy  the  given  lower  and  upper  bound  requirements.  More  specifically,  define  j  to  be  an  initial 
index  for  a  class  C  provided  that  C  is  enabled  in  Sj,  and  either  j  =  0,  or  else  C  is  not  enabled  in 
Sj_i,  or  else  tTj  G  C;  initial  indices  are  the  points  at  which  the  bounds  for  C  begin  to  be  measured. 
Then  for  every  initial  index  j  for  a  class  C,  the  following  conditions  must  hold: 

1.  (Upper  bound) 

If  upper  00,  then  there  exists  k>  j  with  <  tj  +  upperiC)  such  that  either  Tr*  G  C  or  C  is 
not  enabled  in  Sk. 

2.  (Lower  bound) 

There  does  not  exist  k>  j  with  tk<tjA  loweHjC)  and  tt*  G  C. 

Finally,  admissibility  is  required:  if  the  sequence  is  infinite,  then  the  times  of  actions  approach  00. 

Each  timed  execution  of  an  MMT  automaton  A  gives  rise  to  a  timed  trace,  which  is  just  the 
subsequence  of  external  actions  and  their  associated  times.  The  admissible  timed  traces  of  the  MMT 
automaton  A  are  just  the  timed  traces  that  arise  from  aU  the  timed  executions  of  A. 

MMT  automata  can  be  composed  in  much  the  same  way  as  ordinary  I/O  automata,  using  syn¬ 
chronization  on  common  actions.  More  specifically,  define  two  MMT  automata  A  and  B  to  be 
compatible  according  to  the  same  definition  of  compatibility  for  timed  automata.  Then  the  com¬ 
position  of  the  two  automata  is  the  MMT  automaton  consisting  of  the  I/O  automaton  that  is  the 
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composition  of  the  two  component  I/O  antomata  (according  to  the  definition  of  composition  in  1131) 
together  with  the  bounds  arising  from  the  components.  This  composition  operator  is  substitutive 
lor  the  admissible  timed  trace  inclusion  ordering  on  MMT  automata. 

B.3  MMT  Automata  and  Timed  Automata 

”«L“we™  r  of ‘taed  automata.  This  is  because  the  MMT  model 

loLll  TileH  ,  'P«‘fy'"S  the  time  bound  restrictions,  via  the  added  lower  and  upper 

bounds.  Timed  automata  in  contrast,  build  the  time-bound  restrictions  explicitly  into  the  time- 

LrZ  ”ot  hard  to  transform  any  MMT  automaton  vl  Lo  a  natuX- 

corresponding  timed  automaton  A  .  First,  the  state  of  the  MMT  automaton  A  is  augmented  with 

components  for  each  class  of  the  task  partition.  The 

San  actlX  ?  T'^°"n"‘'  7''““'’  P"»«t  and  latest  time  in  the  future 

at  an  action  m  cIms  C  is  allowed  to  occur.  The  now,  first  and  last  components  all  take  on  values 

fir!  I?dT”,  The  time-passage  action  n  is  also  added.  The 

first  and  loaf  cornponents  get  updated  in  the  natural  way  by  the  various  steps,  according  lo  the 

looter  ^d  upper  bounds  specified  in  the  MMT  automaton  rl.  The  time-passag!  ketion  hrexphei! 

Ldh”nes '  “7  T"°‘  teprLnt 

the  r  !  ,  7  R«trictions  are  also  added  on  actions  in  any  class  C,  saying  that 

the  current  time  now  must  be  at  least  equal  to  first(C).  ^  ^ 

of  i".”!-”'  ^  ““"‘'‘“S  of  “  component  iasic,  which  is  a  state 

in  LI  f7l"'F  7  ^  components  firsfiC)  and  last(C),  each 

ms  ‘  i'  ,.  e  aid  s.now  =  0.  Also  if  C  is 

a!d  then  s.>s<(C)  =  Jofer(C)  and  s.las<(C)  =  „pper(C);  otherwise  s.first(C)  =  0 

according  to  its  classificatton  rr"'""  “  “f"’’ 

condm'onfhold"'  ‘f  “f*  foU-"? 

1.  s. now  =  s' .now. 

2.  s.basic—^A  s'. basic. 

3.  For  each  C  €  part{A): 

(a)  If  TT  e  C  then  s.first(C)  <  s.now. 

f ^  ^  =  ^-firstiC)  and  s'.lastiC)  = 

(c)  ^  m  5'  and  either  C  is  not  enabled  in  5  or  tt  G  C  then  s'.first(C)  =  s.now  + 

low€r{C)  and  s  .last{C)  =  s.now  +  upper^C). 

(d)  If  C  is  not  enabled  in  s'  then  s'.first(C)  =  0  and  s'.last{C)  =  00. 

On  the  other  hand,  if  tt  =  1/,  then  s'  —5^,  5  exactly  if  all  the  foUowing  conditions  hold: 

1.  s'. now  <  s.now. 
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2.  s.basic  =  s'. basic. 

3.  For  each  C  G  part(A): 

(a)  s.now  <  s'.lasl(C). 

(b)  s.first(C)  =  s'.firsl(C)  and  s.last(C)  =  s'.last(C). 

The  resulting  timed  automaton  A'  has  exactly  the  same  admissible  timed  traces  as  the  MMT 
automaton  A. 

Moreover,  this  transformation  commutes  with  the  operation  of  composition,  up  to  isomorphism. 
We  refer  to  an  MMT  automaton  and  to  its  transformed  version  interchangeably.  Another  way  of 
looking  at  the  preceding  construction  is  as  showing  exactly  how  the  MMT  notation  is  used  to  denote 
timed  automata. 

The  following  is  a  technical  lemma  that  is  useful  in  some  of  the  invariant  and  simulation  proofs. 

Lemma  B.l  In  all  reachable  states  of  a  (transformed)  MMT  automaton,  and  for  all  classes  C,  the 
following  hold. 

1.  now  <  last(C) 

2.  If  last{C)  ^  00  then  last(C)  <  now+  upperfC). 
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C  Invariants  and  Simulation  Mappings 

We  define  an  invariant  of  a  timed  automaton  to  be  any  property  that  is  true  of  all  reachable  states. 

The  definition  of  a  simulation  mapping  is  paraphrased  from  [16,  15,  14].  We  use  the  notation 
/[s],  where  /  is  a  binary  relation,  to  denote  {u  :  {s,u)  £  /}.  Suppose  A  and  B  are  timed  automata 
and  Ia  and  Jb  are  invariants  of  A  and  B,  respectively.  Then  a  simulation  mapping  from  A  \.o  B 
with  respect  to  1^  and  Ib  is  a  relation  /  over  states{A)  and  states{B)  that  satisfies: 

1.  If  u  £  /[s]  then  u.now=  s.now. 

2.  If  s  e  start{A)  then  /[^j  n  start{B)  0. 

3.  If  s  s',  s,  s'  £  I  A,  and  u  £  f[s]  D  Ib,  then  there  exists  u'  £  f[s']  such  that  there  is  a  timed 
execution  fragment  from  u  to  u'  having  the  same  timed  visible  actions  as  the  given  step. 

Note  that  tt  is  allowed  to  be  the  time-passage  action  in  the  third  item  of  this  definition.  The  most 
important  fact  about  these  simulations  is  that  they  imply  admissible  timed  trace  inclusion: 

Theorem  C.l  If  there  is  a  simulation  mapping  from  timed  automaton  A  to  timed  automaton  B, 
with  respect  to  any  invariants,  then  attraces(A)  C  attraces{B). 
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D  Correspondence  Between  Original  Specification  and  AxSpec 

We  show  how  the  Utility  Property  in  the  original  formulation  of  the  GRC  [7]  relates  to  the  Utility 
Property  in  AxSpec.  In  the  original  formulation,  the  Utility  Property  is  expressed  as  “If  t  ^  U,  [r,  - 
65*^:'  +  6])  then  g(t)  =  90,”  which  can  be  rewritten  as  “If  g{t)  90,  then  t  €  U,[r,-  -  +  ^2].” 

In  the  Lynch- Vaandrager  model,  the  Utility  Property  can  be  stated  as  an  axiom  of  any  admissible 
timed  execution  a:  “If  s  is  a  state  in  a  with  s.Gate.status  up,  then  s.now  €  [r,-  —  -f  ^2]  for 
some  i.” 

In  the  description  of  AxSpec  in  Section  3.5,  the  UtiUty  Property  is  expressed  as 

If  a  is  a  state  in  a  with  s.Gate.status ^  up,  then  at  least  one  of  the  following  conditions  holds. 

o.  There  exists  s'  preceding  (or  equal  to)  s  in  a  with  s'.Trains.T.status=  I  for  some  r  and  s'. now  >  s.now -^2- 

b.  There  exists  s  following  (or  equal  to)  s  in  o  with  s'. Trains.r. status  =  I  for  some  r  and  s'. now  <  s.now  +  (i. 

c.  There  exist  two  states  s'  and  s"  in  a,  with  s'  preceding  or  equcd  to  s,  s"  following  or  equal  to  s,  s'.  Trains.r. status  = 
/  for  some  r,  s".  Trains.r. status  =  I  for  some  r,  and  s" .now  —  s'. now  <  6  +  ^2  -h 

Lemmas  D.l  and  D.2  show  that  the  Lynch- Vaandrager  form  of  the  original  Utility  Property  and  the 
statement  of  utility  in  AxSpec  (parts  a  and  b  only)  are  equivalent. 

Lemma  D.l  If  s  is  a  state  in  a  and  s.now  G  [r,-  —  -)-  ^2]  for  some  i,  then  (a)  or  (b)  holds. 

Proof:  There  are  three  cases. 

1.  For  s.now  €  [r,-  -  ^i,r,],  choose  s'  to  be  the  last  state  in  a  such  that  s'. now  =  r,-.  Then, 
s'. Trains.r. status  =  /  for  some  r,  and  s'  foDows  (oris  equal  to)  s  in  a.  Further,  <  s.now, 
which  implies  r,-  <  s.now  +  ^1.  This  implies  s'. now  <  s.now  A-  ^i. 

2.  For  s.now  G  choose  s'  =  s.  Then,  s'. Trains.r. status  =  I  for  some  r,  and  s.now  > 

s.now -^2  by  assumptions  on  the  constants.  This  implies  s'. now  >  s.now -^2- 

3.  For  s.now  G  +  ^2],  choose  s'  to  be  the  first  state  in  q  such  that  s'. now  =  Vi.  Then, 
s'  .Trains.r. status  =  /  for  some  r,  and  s'  precedes  (or  is  equal  to)  s  in  a.  Further,  s.now  < 
^i  +  which  implies  s.now  —  ^2  <  Oi.  This  implies  s.now  —  ^2  <  s'. now. 


Lemma  D.2  If  s  is  a  state  in  o  and  (a)  or  (b)  holds,  then  s.now  G  [t,'  —  H"  ^2]  for  some  i. 

Proof:  Assume  (a).  Then,  s.now  -  ^2  <  s'. now,  which  implies  s.now  <  s'.nowA^2-  Further, 
s  .Trains.r. status  =  I  for  some  r  implies  <  s'. now  <  i/i  for  some  i,  which  implies  s'. now  +  ^2  ^ 
Oi  +  6-  This  implies  s.now  <  i/,  +  ^2  as  needed.  By  assumptions  on  the  constants,  r,-  -  ^  <  r,-.  This 
implies  r,  —  <  s.now,  since  s'  precedes  or  is  equal  to  s. 

Assume  (6).  Then,  s'. Trains.r. status  =  I  for  some  r  implies  r,-  <  s'. now  <  u,.  Further,  s' 
follows  (or  equals)  s  in  o  implies  s.now  <  s' .now.  By  assumptions  on  the  constants,  i/,-  <  Vi  -f  ^2. 
Hence,  s.now  <  Vi  +  ^2  as  needed.  Also,  Ti  -  <  s'. now  -  ^1.  Then,  s'. now  <  s.nou;-|-  implies 

s'. now  -  <  s.now.  This  implies  r,-  -  <  s.now  as  needed. 
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To  prevent  the  gate  from  being  raised  and  lowered  uselessly,  we  revised  the  Utility  Property  so 
that  the  gate  is  only  raised  if  there  is  sufficient  time  S,  6  >  0,  for  at  least  one  car  to  pass  through 
the  crossing.  To  express  this  added  constraint,  the  original  statement  can  be  rewritten  as 

W  7^  90,  then  at  least  one  of  the  following  holds: 

1.  <€U.h-^i,./,  +f2]or 

2.  t  e  [vi  +  6.  n+i  -  6]  with  r.+i  -  v,  <6  +  ^  +  6  for  some  i. 

In  the  Lynch- Vaandrager  model,  this  is  expressed  as 

If  s  IS  IS  a  state  in  a  with  s.  Gate. status^  up,  then  for  some  i  at  least  one  of  the  following  holds: 

1.  s.noiDS  [r, -l-fj]  or 

2.  s.now  e  [i/,  +  6>  r,+i  -  6]  with  r.+i  -  v.  <  -|-  6  ^ i . 

We  show  the  equivalence  between  the  latter  statement  of  the  Utility  Property  and  the  statement  of 
utility  (parts  a,  6,  and  c)  in  AxSpec. 

Lemma  D.3  If  there  exists  a  state  s  in  a  such  that  for  some  i  either  condition  (1)  or  condition  (2) 
holds,  then  at  least  one  of  conditions  (a),  (b),  or  (c)  holds. 

Proof:  Lemma  D.l  shows  that  if  condition  (1)  holds,  either  (a)  or  (6)  holds.  We  show  that  condition 
(2)  implies  condition  (c).  Let  s'  be  some  state  such  that  s'. now  =  j/,  and  s"  be  some  state  such  that 
s  .now  —  T,'+i.  Then,  by  definition,  s  .Trains.r. status  =  I  for  some  r  and  s" .Trains.r. status  —  I  for 
some  r.  ^rther,  s.now  €  [r,  -  -f  ^2]  implies  s'. now  <  s.now  <  s".now,  so  s'  precedes  5  and  s" 
follows  5  in  a.  Finally,  t,+i  -  t'i  <  ^2  +  ^  +  6  implies  s".now  -  s'. now  <  6  +  6  + 


Lemma  D.4  If  there  exists  a  state  s  in  a  such  that  at  least  one  of  conditions  (a),  (b),  or  (c)  holds, 
then  for  some  i  condition  (1)  or  condition  (2)  holds. 

Proof:  Lemma  D.2  shows  that  if  either  (a)  or  (6)  holds,  then  (1)  holds.  We  show  that  if  condition 
(c)  holds,  then  either  (1)  or  (2)  holds.  There  are  two  cases. 

1.  Suppose  s  occurs  during  the  interval  [r.  -  -|-  ^2]  for  some  i.  Clearly,  (1)  holds. 

2.  Suppose  s  occurs  during  the  interval  [i/i-t-^2,  for  some  i.  Then,  s'.  Trains.r. status  =  I  for 

some  r  and  s'  precedes  or  is  equal  to  s  implies  s'. now  <  i/,.  SimUarly,  s".  Trains.r. status  =  I  for 
some  r  and  s"  foUows  oris  equal  to  s  implies  s".now  >  r.+j.  Hence,  s". now- s'. now  >  r,+i  -i/,. 

This  together  with  s".now  -  s'. now  <  +  6  +  ^  implies  r.+i  -  i/.  <  6  +  6  +  ^-  Therefore,  (2) 

holds. 
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E  Proof  of  Relationship  Between  Op  Spec  and  AxSpec 

We  prove  Lemma  4.3.  We  first  prove  an  easy  property  of  OpSpec: 

Lemma  E.l  Let  a  be  any  admissible  timed  execution  of  OpSpec.  Let  w  be  any  lower  event  occurring 
in  a  from  a  state  in  which  Gate.status  €  {going-up,  up}.  Then  there  is  an  enterl  event  <f>  occurring 
after  tt  in  a,  with  time{<l>)  <  time(7t)  + 

Proof:  Suppose  that  tt  occurs  from  state  s,  leading  to  state  s';  then  time{-K)  =  s.now  =  s'. now.  If 
s.lasti  =  00,  then  the  effect  of  /otocr  implies  that  s'.lasti  =  s'.now+^i.  Otherwise,  part  3  of  Lemma 
4.2  implies  that  s'.lasti  <  s'. now  +  ^i.  Thus,  in  either  case,  s'.lasti  <  s'. now  +  ^i. 

By  the  precondition  for  the  time-passage  action  and  the  fact  that  only  enter/ actions  can  increase 
lasti,  real  time  cannot  pass  beyond  s'.lasti  unless  a  train  enters  /  at  a  time  <  s'.lasti  <  s'.now+  ^i. 
But  a  is  an  admissible  execution,  so  time  passes  to  oo.  It  follows  that  there  must  be  an  enter/ event 
</>  occurring  after  tt  in  a  such  that  time((f>)  <  time{-K)  -f  fi.  ■ 

Now  for  the  proof  of  Lemma  4.3: 

Proof:  Let  a  be  any  admissible  timed  execution  of  OpSpec.  By  assumption,  a  satisfies  the  Safety 
Property,  i.e.,  the  safety  invariant  is  true  in  all  states  of  a.  We  show  that  it  also  satisfies  the  Utility 
Property. 

Let  s  be  any  state  occurring  in  a  with  s.  Gate.status  7^  up.  If  s.Trains.r.status  =  I  for  any  r,  then 
the  claim  is  immediate.  So  assume  that  s.  Trains.r. status  7^  /  for  all  r. 

Since  s.  Gate.status  ^  up,  it  must  be  that  there  was  a  previous  /ou?er  event  occurring  from  a  state  in 
which  Gate.status  €  {going-up,  up}.  (Consider  the  possible  transitions  in  the  automaton  Gate.)  Let 
TT  be  the  last  /ou;er  event  preceding  s  that  occurs  from  a  state  in  which  Gate.status  e  {going-up,  up). 
Then  Gate.status  7^  up  in  the  entire  interval  from  just  after  tt  to  s.  Also,  time{‘K)  <  s.now. 

By  Lemma  E.l,  an  enter/ event  occurs  within  time  after  tt.  Let  <t>  be  the  first  such  enterl 
event.  Thus,  time(<l>)  <  time{w)-\-^i  <  s.nouj-t-^i.  By  the  Safety  Property,  Gate.status  =  dou:n  when 
<t>  occurs.  We  consider  two  cases. 

1.  <f)  is  after  s. 

Then  take  s'  to  be  the  state  just  after  d>-  Then  s'. now  =  time{4>)  <  s.nouj-f  ^1,  and  so  s' 
satisfies  the  axiomatic  Utility  Property,  part  (b). 

2.  ^  is  before  s. 

Since  (by  assumption)  there  is  no  train  in  /  in  state  s,  we  can  find  a  latest  exit  event  ij)  following 
(f)  and  preceding  s,  which  must  leave  I  empty.  When  occurs,  the  lasti  variables  are  set,  which 
ensures  that  either  the  gate  reaches  the  up  position  within  time  ^2  after  or  some  train  reaches 
I  within  time  I2  +  ^  +  ^1  after  V'-  We  consider  two  subcases. 

(a)  s.now  <  time{ij;)  +  ^2- 

Then  take  s'  to  be  the  state  just  prior  to  Then  s'. now  =  time{il})  >  s.now—  ^2,  and  so 
s'  satisfies  the  axiomatic  Utility  Property,  part  (a). 
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(b)  s.now>  <?me(^)  +  ^2- 

Then  the  gate  cannot  reach  the  up  position  within  time  ^2  after  xp,  because  Gate. status  ^ 
up  throughout  the  interval  from  tt  to  s.  So  it  must  be  that  some  train  reaches  I  within 
time  6  +  <5  +  6  after  That  is,  there  must  be  some  enterl  event  V’'  following  xp,  with 
time{xp')  <  timeixl})  +  ^3  +  <5  +  6- 

We  claim  that  xj}'  must  follow  s.  For  if  it  did  not,  the  fact  that  /  is  empty  in  s  would 
imply  that  there  must  be  an  exit  event  following  x/x'  and  preceding  s,  which  contradicts 
our  choice  of  xj).  Then  take  s'  to  be  the  state  just  before  xp  and  s"  to  be  the  state  just 
after  xP'.  Then  s".noxv- s'.noxv  =  time(xP')  -  time{xP)  <  6  +  ^  +  6  •  Thus,  5'  and  s"  satisfy 
the  axiomatic  Utility  Property,  part  (c). 
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